by Brett g Porter
posted Feb 14, 2003
As GoAhead's support partner for the open source WebServer, we often encounter engineers who tell us that they are planning to undertake a web-based device management system using the GoAhead WebServer and "a little CGI code." There are no doubt some small or essentially discardable systems where this approach makes long-term sense, but they are fewer than one might think. Many of the reasons that web developers have moved away from using CGI to implement dynamic web sites are just as valid (if not more so) when building web interfaces for embedded devices.
First, any CGI-based solution is going to be slower than an equivalent in-process Application Server approach. On each request to a CGI application, the operating system must fork a new process to handle the request, then launch the specified CGI application and pass parameters to the application's standard input. On large-scale web servers (like Apache) there are add-on modules (like 'FastCGI') that lessen the impact of executing CGI applications. Also, the fact that the CGI application operates in its own process space means that any useful data structures or variables that may exist inside the web server process are not available to your custom code without adding an IPC layer to handle this.
CGI applications also present several challenges that may only become obvious once an interface design reaches a certain complexity or scale. The first difficulty encountered when programming CGI applications is the practice of "web programming by printf." For a simple CGI application that processes a small form and then displays a simple result or redirects the user's browser back to another static HTML page, there are no apparent problems. However, when the complexity of the response grows, the C programmer is forced to emit complex blocks of HTML from C code. Two unfortunate cases arise from this approach; either the C programmer spends time gaining HTML expertise (or more often, creates a web interface that looks like a C programmer designed it), or they must copy and paste blocks of HTML created by a web programmer using traditional web development tools. In the latter case, whenever the layout of the HTML pages change, the programmer is forced to repeat this HTML to C translation. In either case, any change made to the interface during development requires a compile-link step that greatly reduces the speed of development. Requiring that the interface be generated by C code also removes the possibility of replacing or updating the web interface in the field without replacing the entire binary image of the server, or of supporting several different web interfaces for the same device, as is often sought after by companies who create devices that will be resold by OEMs. On the other hand, Art & Logic has developed techniques and code libraries that let the server-side programmer and web interface programmer work independently, in parallel, each using the best tools for their respective roles on the project.
Using CGI to implement a web-based device management system often seems attractive in the early stages of a project's lifecycle. It's fairly typical for these projects to start their life as relatively small things. Often a web interface is added to a device at first to do nothing more than check off an item on a bullet list of marketing requirements. After that first small prototype is shown, however, the scope of the web interface almost always seems to expand. Then, for any reasonably complex device, the problems involved with trying to scale up a CGI-based system become quickly apparent. Compared with an application server like Art & Logic's Device Management Framework (DMF), CGI might seem to have a lower cost and a more manageable learning curve. However, as the scope of a device's web interface grows, it becomes clear that the learning curve involved with the DMF is all about using pre-written, tested features; not about learning how to implement and test those features by yourself as your project's scheduled ship date creeps closer. Consider the effort required to implement some of the features present in the DMF:
Since the DMF is included with Art & Logic embedded web development services, these essential tasks are handled, thereby freeing you to concentrate on coding the features that make your product unique and valuable.
Brett g Porter is Art & Logic's Chief Engineer of Development Practices. Before Art & Logic, he worked in the broadcast electronics industry designing software to monitor FM stations, broadcast data, and distribute audio via satellite, picking up a patent along the way. Before that, he got two degrees in Composition, but decided to become a productive member of society.