Common Gateway Interface (CGI) is a standard method to generate dynamic content on web pages and web applications providing the interface between web server and programs to deliver content. This medium was created and grew in popularization as a standard way to create web content since the late 90's. CGI programs are typically designed in PERL for host platforms and C/C++ in embedded devices since PERL is typically too CPU and memory intensive for embedded devices. Each web-page managed by CGI is typically designed as a standalone computer program, and it is therefore not uncommon to have a large number of CGI programs in a CGI managed web-application.
CGI cannot be used in embedded devices if the operating system does not support the process model since CGI is an API, based on passing environment variables from a web-server to an external process. The following comparison therefore applies to using a web-server with operating systems such as embedded Linux and QNX.
Envision that your objective is to create a water container. To meet this criteria the natural selection would be to start with something that may resemble a bucket. When we compare CGI in analogy, the solution provides a starting point which is equivalent to that of a strainer. Consequently, the application developer must spend a considerable effort identifying and sealing all of the holes of this strainer (CGI).
Unfortunately, CGI has no inherent or native security built into its structure, and with its many vulnerabilities, it creates a struggle to maintain such a solution in today's IoT generation of devices. Manufacturers are becoming increasingly aware of these problems, but usually as a casualty of consequence in the daily news rather than the advanced step to negate avoidable liabilities.
CGI is particularly slow in embedded devices with limited CPU since the web server must request the operating system to load, initialize, and execute the external CGI processes. A CGI process is typically loaded, initialized, executed, and terminated by the operating system for each web-page accessed. Starting up the CGI process takes up much more time and memory than the actual work of generating the output. Due to speed issues, web-applications designed using CGI in CPU limited devices will in many cases be too impractical for normal use. The users of the web-application may become impatient and regard the web-application of poor quality.
In Barracuda, web applications are extremely fast as they are part of the server if designed in CSP or loaded into the server at startup if designed in LSP. Additionally, since Barracuda is designed from the ground up for resource constrained devices, web-applications designed using CSP or LSP are generally blinding fast.
Lua Server Pages, or LSP for short, and C/C++ Server Pages, or CSP for short, are technologies that enable you to make dynamic and interactive web pages. LSP is similar to CSP except that LSP does not need to be compiled. Lua is a lightweight functional programming language, designed as a scripting language with extensible semantics as a primary goal.
One can find many discussions online when searching, for example, on Google for CGI versus ASP, or CGI versus PHP, etc. One soon gets a more clear understanding that developing CGI applications are much more cumbersome than more modern alternatives. These discussions are typically related to CGI developed in PERL or other high-level scripting languages. A CGI process developed in the C/C++ language is for obvious reasons much slower to design than to design a CGI script in PERL or any other scripting language. In addition, a CGI C/C++ framework must either be developed or purchased separately. This framework/library must be linked with all CGI programs (pages) developed, and CGI applications for embedded devices become extremely tedious and expensive to develop. CGI processes designed in C/C++ scale poorly, and it can become very expensive to add features and/or change web-applications designed using CGI.
Barracuda, on the other hand, provides a feature rich and easy to use web-framework that CSP and LSP applications can take advantage of. We dare to compare our LSP plug-in in functionality and ease of development with high end application servers such as those that can run ASP .NET web applications.
We often get questions about the size of the Barracuda Embedded Application Server, though customers typically do not think about the size of the web-application, which can easily and rapidly increase in size. A CGI based web-application designed in C/C++ increases in size rapidly as pages are added. Barracuda stores applications designed in LSP as ZIP files, thus considerably reducing the size compared to CGI based web-applications.
The difference between an application server and web server is explained in the What is an Embedded Application Server tutorial.
From experience, we know that designing device management applications using web servers together with basic application frameworks such as CGI take a significantly longer time to develop than device management applications designed using the Barracuda Embedded Application Server. Thus our product drastically reduces the overall price and time to market for the complete device management application.
Try the Barracuda Web/App Server by downloading your own copy or try our online interactive tutorials.