Server side software interface between web server and hardware

[szmoore]

We need to be able to process a web browser request and respond with data from sensors and/or activating output devices.

Either:

1. Reading/Writing to Raspberry Pi GPIO directly
2. Reading/Writing via USB interface to some other device with direct control over sensors/actuators.

Some progress can be made before we need a final decision on which method is preferred. The Raspberry Pi GPIO may be needed even if a second device is used, so that will be tried first. An AVR Butterfly can be used as a test device pending final decision on what (if any) device will be used to interface with sensors/actuators.

[szmoore]

CGI (Common Gateway Inferface) is a method to run programs under the control of an (apache2) web server.

My original idea was to have a CGI program interface with another program which runs in the background on the server and handles lower level tasks. This would require inter process communication such as pipes or Unix sockets between two different programs.

An alternative approach is to implement a minimalist web server and the low level control/sensor software in the same program, using threads. I believe this would be much more efficient, since with the CGI approach there are actually three levels involved, although we don't need to implement one of them (web server -> CGI program -> low level control/sensors).

There are also a lot of features provided by the web server (access to more than one client, indexing of files, etc) that we don't actually require. So I will investigate implementing a very minimal web server. Software to interface with low level devices can then be added to the web server and run in the same program, probably in a separate thread.

Essentially we change the interprocess communication to communication between threads in the same process. Which is much faster since threads share the same memory.

The new idea will not work if the client side GUI expects any HTML to be produced by the server.
I believe it will be fairly straight forward for the JavaScript GUI to produce all required HTML and CSS, and just parse plain text to update the GUI.

[szmoore]

We've decided to write a HTTP server running as a thread in the same process as the sensor/actuator code. CGI scripts would require too many layers of interprocess communication, and would probably be more difficult than writing a custom HTTP server, which turned out to be not that hard.

[szmoore]

Jeremy suggested FastCGI, which gets around the disadvantages of CGI by running continuously. An existing HTTP server (nginx) passes the requests to the FastCGI program; from the program's point of view they show up as strings just like they would look if you wrote a custom HTTP server and then passed the requests to a function.

Essentially FastCGI will do the same thing I was thinking of doing with the custom HTTP server; we run the FastCGI part in one thread and sensors/actuator stuff in other thread(s).

The main advantage of using FastCGI is that although it is easy to write a custom server that can handle the HTTP requests, if we want to add more functionality (such as https, authentication, etc) it will be easier to use an existing web server that already has modules for these things.

I already wrote a custom HTTP server, but I think it is a good idea to switch to FastCGI.
We still have the option of changing to a custom HTTP server or even a server that keeps a dedicated connection open (as opposed to HTTP which is stateless) using the code I already wrote.

[szmoore]

Should probably note that we're using a Beaglebone Black now, not an RPi.

[szmoore]

It currently works well using FastCGI and it would be very silly to reinvent it.

[szmoore]

A limitation of Flot and/or JavaScript in the GUI will probably be reached before a limitation with the speed of FastCGI and the server program (not that there will be a limitation with the speed of FastCGI or anything else if you put enough data through it).

It is possible to implement a HTTP based GUI in any language without being restricted to a web browser. If a faster sampling rate is desired for future experiments and a JavaScript GUI is too slow, then this could be considered.

See "pygui" under the "testing" directory.