JeeMon comes with a nifty built-in HTTP/1.1 web server (using coroutines to handle requests in parallel).
So let’s create another real-time status display, but as web application this time:
As before, I’m leaving out the lipstick – just showing the core functionality.
Here’s what I did to generate this page. First of all, I’m re-using some functionality which is already in the GUI version, to dynamically construct a matrix with the proper columns and rows, so the “statusWindow” code has to be running for the above to work. For real use, that code should probably be reorganized into its own rig.
The main task was to create a HTML template in a file called “statusPage.tmpl”:
This uses a simple templating mechanism based on Tcl’s “subst” command. The meta tag sets up the page to self-refresh every 5 seconds. The last line tells the Wibble web server to deliver the page as HTML.
To launch the server, this line was added to the main application file (port 8080, current dir is doc root):
That’s it – there’s very little to activating a web server in JeeMon, as you can see. Which is important, because on tiny embedded Linux systems, an HTTP server will probably be the only option to present information.
Creating a full-blown site with CSS, JavaScript, and Ajax is a matter of adding more files – the usual stuff…
Did I mention that it’s all 100% open source, so you can browse / extend / change all of this? – I did? Oh, ok ;)
It looks like metakit is around the corner :)
Whenever you get to that, just a small request: For us who are not familiar with metakit, it would be cool with a little blurb about how metakit differs from typical other databases which could be used for this purpose (sqlite, berkeley db or even postgresql). ..or maybe even abstract away the database interfaces in JeeMon to make it trivial to choose smth. familiar as a backend, which could be useful if one is to integrate data collected from jeenodes into larger or existing systems.
I really enjoy your blogposts describing the jeemon system while it’s being designed/evolved. Keep up the good work!
The plan is indeed to abstract away from any particular DB interface. It’s a bit more work, I haven’t figured it all out yet…
Glad to hear you like the weblog!!!
Hi Jean-Claude,
very interesting work!
Because as you say “on tiny embedded Linux systems, an HTTP server will probably be the only option to present information.” you might be interested in making such an embedded server accessible to any browser without having to worry about public IPs, NATs or firewall settings.
We are currently developing Yaler, a simple, RESTful, open source relay infrastructure solving exactly this problem. Please visit http://yaler.org/ for more information on the project.
Kind regards, Thomas
Yaler looks inteRESTing ;) – what would it take to hook up to it? I’m still having some trouble wrapping my head around how it will work in practice – but I’mm sure that’ll improve soon enough. Look also at tomorrow’s post for some “push” processing.
@jcw: To hook up to Yaler your embedded server will have to turn into a HTTP client until the Reverse HTTP connection is established. Reversing usually requires access to the socket of your outgoing HTTP connection. After this initial handshake everything remains as it is now, as long as you serve relative URIs only. Otherwise you’ll have to rewrite the host part of the URI, eg. http://device-IP/my.html becomes http://yaler.net/device-ID/my.html . That’s it.
Just driving by — JC, this stuff is awesome. Your ideas are so on target for this new world of sensors connected everywhere. I just found your site and the combination of low-power radio + cheap nodes is, well, awesome! Thanks for working on this project for us all.
Heh, thx! :)