How to implement a web GUI front-end?
 

Not sure if this is the best place to post this but since I'm working with an embedded Linux SBC I'll start here.

I'm interested in building a web browser front-end for my SBC system. Two big things I'd like to be able to do are 1) configuration/setting preferences and 2) actually control a C/C++ application running on the SBC.

Seems like every router on the planet does #1 so how does this work? What technologies are used? Are we talking CGI scripts? Perl? PHP?

As for #2, I've read one-liners that seem to suggest you should write a Java applet that would create the GUI. Seems like every web camera does this sort of thing.

Is any of this correct and more importantly, is there a book on the subject?

Hi -

No:
1. Very often, the user interface on the Single Board Computer itself is command-line only (for example, Busybox).

2. The OS will have an embedded web server.

3. The "GUI" is just HTML, rendered by your (external!) web browser.

4. On the SBC, you can use C/C++ (commonly), embedded Perl (perhaps even more common) or just about any language you wish (including Java) to handle your web responses.

This is actually *good* news for you. It means your "GUI" is just simple HTML. Easily several orders of magnitude less difficult than even a Java applet.

Embedded or not, the web/interface layer just sets variable values.
 

So at the most basic level, what you need is to parse an XML or html file, and make the parsed text set the values of variables in C/C++.
I just did
... in Debian 6.0, and got about three full pages of program names. So the good news is that there are many programs that can do what you want, and you get to choose the one(s) that is/are best for you. And the bad news is that there are many programs that can do what you want, and you have to choose the one(s) that is/are best for you. :D

Okay, let me rephrase and clarify. Yes, the SBC is running Busybox (v 1.7.4 IIRC and building a newer version is doable). I've got the system configured to run httpd, ftpd, and telnetd and I've served up a basic HTML page so I know all of this is working.

Now, let's work this with an example: Say you have a sprinkler system for a golf course with GPIO lines controlling the valves but you also have some ADC lines for temperature, humidity, and rainfall. The C++ program running on the SBC takes care of running the system and is smart enough to not water anything when it's raining but it also has some sort of sensor that shuts off the sprinkler when a golfer comes by. And lets say that there are water flow sensors so you could know that water is flowing when it's supposed or not (to let you know that valves are actually functioning).

What you'd want is a web interface that updates live (as opposed to having to refresh/reload the page) with the status of the inputs. Perhaps you'd want to view the flow rate as an analog variable. Buttons to control the valves, etc.

So, plain HTML isn't enough. I'd prefer not to have to write a platform-specific app (Windows, OSX, Etc) so is a Java applet the way to go?

Have it report via snmp. Then you could use something like Nagios or Icinga to do the monitoring live.

No, No, No!

Your web GUI will be run on a client (web browser). Your work is on the server end.

If you are trying to control/monitor a specific application, then you can build a primitive HTTP server into the application. If you are trying to control the host more generally, then you can either use an existing or create your own HTTP server. Then, use CGI or PHP applications on the HTTP server to control the host parameters as necessary. Depending on the application requirements, you may have to relax the security with respect to what a traditional web server would do.

The actual GUI aspect of the application can be as simple as plain vanilla HTML (generated by your CGI/PHP/other code), all the way through to sophisticated Java applets that are downloaded to the browser. Still, on the server end, you simply have to parse and handle HTTP request messages, which is about an order of magnitude simpler than parsing and interpreting HTML. Using Perl or PHP it is almost trivial.

Writing an embedded HTTP server in your application can be relatively simple. The basic functionality can be implemented in about 100 lines of C code, for simple things like setting simple parameters, or displaying status information.

To help get a basic understanding of the underlying mechanics, I suggest that you undertake some simple CGI programming in a traditional web server environment, such as Apache on Linux. Use Perl, C, PHP, whatever. You can start out by generating basic HTML, and add bits of javascript as you get more conversant in the process. Once you understand how that works, you will probably see where you need to go to accomplish your final goal.

--- rod.

Process control and monitoring can be accomplished with plain HTML using timed refreshes. If you require finer granularity of time, or if the total screen refreshes are unacceptable, then you will need to use Ajax techniques (typically implemented in Javascript) to update specific screen elements on the browser. I suggest you try the former, and see if you find it acceptable, as it is much easier to implement.

At the server end, your code would receive requests as either HTTP GET or HTTP POST requests, and return the specified data by reading from whatever is the source of the information. This might mean reading directly from IO points or reading from or writing to device drivers.

Your application seem to share enough of the same requirements that you may find it useful to inspect how an embedded HTTP server was implemented in the bacnet4linux project. See in particular the source file html.c. There is a single function in there that handles the receipt of HTTP requests. Also, inspect a lot of the embedded HTML data that is in the C sources, as the method of managing the GUI refresh and some other possibly useful techniques are in there.

--- rod.