[Elphel-support] Web based elphelVision, PHP thoughts, mods

[Gary Mort]

I am looking around for something to hack on for an anniversary gift for 
my wife[a digital camera with a high shutter speed/response time].

DSLR's are out of my range.....and while the Elphel components are the 
same cost, looking at the layout I can purchase components a over time 
and hack around with it to eventually achieve the camera she desires.

While the Elphel seems primarily a video camera, it looks like it also 
can support all the features one needs in a digital camera.  With the 
added benefit that it has an existing PHP api and I am a PHP coder, so I 
can code everything for her precise desires.

If I'm barking up the wrong tree, please let me know.

Naturally I'd like to be able to pick away at this over time, so I 
wanted to know if there is any way I can set up a "virtual" elphel to 
test on[if it helps any, I am currently running a Eucalyptus/Xen server 
at home so I can provide a virtual machine to run it on].

Barring that, if anyone is interested in a PHP/web based interface and 
can connect their elphel to their network to allow me remote access so I 
can test out code and such, I can work on accommodating your desires as 
well as mine.

As for interface design and PHP coding, I'm thinking of the 
following[some of which breaks or augments current design]

One: No CLI code.   Since the Elphel is running a FastCGI server 
already, it makes absolutely no sense to me to run PHP in a CLI 
environment.  Running in CLI mode requires loading a completely seperate 
PHP interpreter into memory to run the code.  Wheras a shell script can 
be used to connect directly to the FastCGI server and have the server 
execute the php code and return a text based response[as opposed the an 
HTML based response]....  So my feeling is it is better to use the 
resources already committed than to grab more.

Two: Code design to use an MVC model.  MVC stands for 
Model-View-Controller, and basically says that all the "programming 
logic" code goes into the "Models", while all display oriented code goes 
into "Views", and you have "Controllers" to organize the execution of 
code.  This way both the text interface and the web interface can use 
the same model and controller files, with just a change in view files 
based on the capability of the client.

Three: Use APC or some other PHP cache.   To speed processing, 
frequently executed PHP files can be cached in memory, avoiding having 
to continually read and compile the PHP files.

Four:  My gut inclination is to use Node.js instead of Lighty for the 
HTTP server...while lighty is a nice, small, fast web server, I expect 
that at times I am going to want to make some small tweaks at the web 
server level.  I am much more comfortable coding such tweaks in 
Javascript which Node.js supports than in C++ for Lighty....so it seems 
a better use of my time to choose the more comfortable option.  Is there 
any reason for sticking with Lighty?

-Gary