This is the LBTI web presence. The server root is www.

The implementation uses lighttpd with the fcgi plugin for the web server, Qt and fast-cgi to gateway
INDI to and from web clients which are built using javascript, jquery and jquery-ui. Apache works fine
also with the appropriate fcgi plugin.

To start the server run bin/spawn.sh. The server runs on port 8080. The processes involved are:

  1. indiserver -- the normal INDI socket presence
  2. lighttpd -- a small and efficient web server
  3. indi.cfgi -- a helper app to lighttpd that connects to indiserver as a client and handles INDI requests
    on behalf of web clients.

Take www/lbto.html as an example.

When this page is loaded, the on-load function in indi.js POSTs a getProperties fcgi xml message one time
to the web server. The web server sees it is an fcgi message and passes it to the indi.fcgi helper app
where FCGI_Accept() is waiting in an infinite loop in IndiFcgi::run(). The results of sending the fcgi
getProperties POST is that indi.fcgi sends an INDI getProperties message to the indiserver, connecting
as an INDI client if not already. The POST returns with no arguments. In response to the getProperties,
the indiserver sends INDI def* messages to indi.fcgi where they are queued for possible later delivery.
The arrival time of each message is recorded.

Meanwhile, the web client, after issuing the initial fcgi getProperties, starts an infinite loop
of POSTs, indi.js::update(), which sends an fcgi delta xml message to the web server. The delta POST
contains one attribute: the time of the most recently received INDI message. Initially this value is
zero so the first delta, in effect, asks for all queued INDI messages.

When indi.fcgi sees the delta POST, it loops through all queued INDI messages and responds with those
that are newer than the time stamp contained in the message. Included in the response is the time of
the newest message sent. The web client records this value and uses it for the next delta POST. In this
way, the web client repeatedly gets each INDI message exactly once. While interating through the list,
indi.fcgi also removes any messages that are older than the age argument given to indi.fcgi when it was
executed (which is 30 seconds by default).

In order to do something with the INDI messages that arrive, the web client registers callbacks
by calling setPropertyCallback. update() gives the list of new messages from the delta response to
indi.js::updateProperties() which dispatches the callbacks, if any, that match the device and name 
attributes in each INDI message. In this way, web clients can do things such as display or draw
as INDI messages arrive.

So far we have covered how a web client receives INDI messages, which is functionally equivalent to
the getINDI command line tool. In order to set an INDI property, the analog to setINDI, the web client
just calls indi.js:setindi() which POSTs the type, device, name and each element as an fcgi message and
indi.cfgi sends this on to the indiserver reformatted slightly as an INDI message. In this way the
web client can set INDI properties in reaction to user input, manipulation of jquery-ui controls, etc.

That's it for the common INDI infrastructure. The remainder of lbto.html just displays info as
INDI properties arrive and sets INDI properties as the user interacts with the web page.

Other resources:

http://www.clearskyinstitute.com/INDI/INDI.pdf
man pages for getINDI, setINDI, indidevapi and indiserver.