(E)mbedded (W)eb (S)erver (I)nterface 1.0.0
Entry posted by Drew_Benton ·
2,408 views
This post will talk about the (E)mbedded (W)eb (S)erver (I)nterface library I have been working on the past couple of days. In addition, this will probably be the last major post about the library for a while since I need to move on to more tech demos of other things. I'm not going to give up the project, but I've reached a point where I need to work on other things before investing more time on using the library in a practical application. In other words, I've put in the time to developing the library now because later I'll have a need for it and it'll be ready.
The purpose of the EWSI library is to provide a simple and easy to use interface to develop an embedded web server in your application. The library gives you all of the basic tools you need to be able to utilize existing web technology in your own applications. The library itself does not actually implement a full web server; that is the task of the end user. This library saves an end user the time from: Having to create a TCP server, processing basic messages sent over HTTP, creating a C interface that allows the library to be utilized by many languages on the Windows platform, creating a Lua binding for the API, and creating a library that is meant to be reused in a multitude of applications.
So, to be clear, this library does not provide anything that an ordinary programmer could not come up on their own. There is nothing new or innovative about this library. Instead, it provides a convenience by saving time for the end user so they do not have to invest the time into coming up with their own solution for the task. This of course, is why most middleware is created.
The EWSI library was designed operate from the end user's main thread. This was done to ensure it'd be compatible with virtually any project. It is a thread safe library, so it can be used from multiple threads if needed. If Lua is being utilized, then the library should not be used in a multithreaded environment due to the nature of Lua not being thread safe by default. The Lua bindings that is provided through the engine API has a limitation of being able to support only one Lua state at this time.
The basic major execution flow for the EWSI library is as follows:
1. The user loads the EWSI library and registers an error callback function.
2. The user creates a server and registers callback functions.
3. The user calls an EWSI API function to update the server once per their main loop cycle if running in a single thread
4. The user handles any events as the callback functions are invoked.
5. The user unloads the EWSI library when their application is about to close.
There are four types of callbacks right now. There is a global error callback that is invoked whenever there is an error generated in the library. There are also callbacks for the server when a client connections, a client generates an error, and a client makes a request. Through logic implemented into these callbacks, a web server is created. A basic static content serving server would just process the path of the GET requests clients generated. It'd load files from disk and send them back to the client or send 404 Not Founds if the content didn't exit.
A dynamic content serving server would work similar to PHP or ASP for example. The server would load templates of pages and then during request processing, fill in content as needed and return the resulting output to the client. This is a more advanced concept, but all it requires is an end user to implement their own content processing logic and then send the resulting output just as it'd be done with static content. The EWSI library itself gives you the core tools to do whatever you need to (although there are certain limitations right now in terms of the internal HTTP processing since it's simple).
Now for the API of the EWSI: http://drewbenton.pastebin.com/WK4QumKj The API has been designed with simplicity in mind as well as ease of interoperability with other languages. As a result, integers are used for pseudo-handles rather than pointers. Rather than worrying about allocation issues between a DLL and an EXE host, the library provides the means for a user to obtain how much memory will be needed first. Then, the user can allocate the memory however they need to on their side and pass it to through the library API functions for data to be written into the memory. Naturally, to use this library with other languages, the language has to support being able to load DLLs, allocate contiguous blocks of memory, and support stdcall calling conventions.
Here is a full example of the EWSI C API in action: http://drewbenton.pastebin.com/Q0efMxJX This program shows off the usage of all API functions, excluding the Lua one which comes next. Rather than handle each error, abort() is put into place of where error handling logic should go. The demo shows "Hello World" in the web browser on any request and outputs debug information as it runs.
The Lua bindings provided internally try to mirror API access as consistently as possible. However, there are some mechanics that would not make sense, so they are changed slightly. An example of a Lua program that uses the Lua API for the EWSI can be found here: http://drewbenton.pastebin.com/WbZZXCb0 As you might notice, any API function that will copy data does not require the length of the input buffer as that is handled internally. Rather than pass a buffer, a global variable name is used. The host program that calls that Lua script can be seen here: http://drewbenton.pastebin.com/YCMXYgyQ
Attached is a (binary version) package that can be used for playing around with it if anyone is interested. Please read the license. I am not currently setup with my own site, forums, instant messaging, or anything else for dealing with any of my work I release. Until I am, I don't want anyone coding their projects into a corner with a dependency on something I've written that I can't support, take suggestions for, track bugs, or update on a regular schedule.
Eventually, I'll be properly setup to handle all my projects and releases in an organized manner. Having seen how nice IP.Board is here at Leadwerks, I'd definitely setup a system using that technology instead of VBulletin. I've never been overly happy about the feel of VB whereas I loved this IPB the first time I browsed the site and started posting.
Anyways, that pretty much wraps up this post about the EWSI library. I'm off to start working on some new tech demos utilizing Leadwerks 2.3 now. Thanks for reading!
2 Comments
Recommended Comments