[time-nuts] beaglebones, time, web services

[Jim Lux]

On 7/7/15 9:59 PM, Brian Inglis wrote:
> On 2015-07-04 07:13, Jim Lux wrote:
>> I've got a project I'm working on to make a sophisticated sundial with
>> moving mirrors.  I've got a batch of Arduinos that move the mirrors to
>> the appropriate places, given the current sun angle, etc.
>> I've got a beaglebone that runs some python code to calculate sun
>> angle based on time
>> The beaglebone will have a GPS feeding it to get time.
>> BUT now, I'd like to add a web interface, so that it can be
>> manipulated by a mobile device using a browser.
>> One way I can think of is to run some sort of limited web server.
>> there are a couple that come with the beaglebone, including the python
>> "simplehttpserver".
>> But I'm sort of stuck on the interface between the webserver and the
>> other code running.
>> I've done this kind of thing where the one task goes out and updates
>> files in the tree that's being served by the web server, and that
>> works fine for "status display" kinds of things that don't update very
>> quickly. It's also nicely partitioned.
>> but I want to be able to change the behavior of the system (e.g. by
>> having the server respond to a PUT or something)
>> Is the best scheme to go in and modify the webserver code to look for
>> specific URLs requested, and then fire off some custom code to do what
>> I want?
>
> May want to start with a control web page with an HTML FORM element and
> embedded input elements - easy even if you have not done much form
> design and entry implementation.
> Submit target can be any URL designating a Python CGI script, which
> generates at least a Content-type header and HTML on stdout returned to
> the browser.
> HTML output normally includes a copy of the original FORM (with values
> passed selected for editing) as well as HTML output and maybe inline or
> linked graphics.
> You only need a web server that supports the CGI interface, with some
> way to configure it and say where the scripts are.
> See Python cgi, html, http module docs to DIY.
>


Yes, that seems to be the way..
The interesting thing is that the cgi needs to return reasonably fast, 
or the user client will timeout, so it's not a good way to do something 
that takes a long time.  Great for "put parameters in a file" or "send 
short command out IO device", not so great for "start long running 
process that needs to continue after user has gone on to do other things.

So it comes down to lashing up some sort of interprocess communication, 
whether it's a named pipe, a file that is shared between two processes, 
IP sockets, etc.