The Elphel PHP is a great reference here: http://wiki.elphel.com/index.php?title=PHP_in_Elphel_cameras

working here : https://lite5.framapad.org/p/eLstD0Zxif

I put some information in the pad, what do you think about it?

Very interesting, thanks.
For a first step, I'd like to work with a minimalistic approach. Symphony seems a bit overkill for what we want to achieve. I'd start with the smallest working prototype than build on top of that.

Waiting for more feedback before jumping in :-)

By the way @WedgeSama, welcome to the lab !

Another interesting read : http://lcsd05.cs.tamu.edu/slides/keynote.pdf

This looks like a nice and lean alternative to symphony : http://lumen.laravel.com/docs/introduction

Indeed, lavarel can be a good chose. In fact, it is base on many Symfony components but it is maybe more easier to work with it instead of the full stack Symfony framework.
I hope I will soon have time to help for the web interface.

My current take on this, is that we should follow Laravel Lumen methodology, and first agree on writing the api documentation then implement it.

Great, what would be the next step?

To help in the api spec/doc, a language exist for that: RAML (http://raml.org/). Clear and simple to understand, it can be good to use it, what do you think about that?

And the plus, there are some generators using RAML files to create nice HTML doc.

RAML looks nice, but probably a bit too complex in the initial brainstorming phase. We could first define what "stuff" will be read / written / created/ deleted from the camera, then write the api specs.

For me it would be (quick brainstorming)

Values :

Get / set :

• shutter speed
• ISO
• gain
• white balance
• gamma
• lut used?
• frames per second
• image dimension (or crop ?)
• current time
• any interesting sensor parameter (as provided in the current php UI)

also : get mins and max for each of those values

Get (read) only :

• various temperatures
• sensor type
• boards revisions
• power voltage
• power consumption
• run time

Actions :

• start/stop sensor
• start/stop hdmi
• various ethernet/network config (might be dangerous from the api side as it might kill the api connection :-))

This is already quite a big api :-)

For the network config, it can be done in two step (same for others critical stuff):

Step 1 :

• Send data to change through API
• Save current config
• Apply sent config

Step 2 :

• Confirm via API the new config
• If the cam receive this, apply the config for good
• If dont, get back to previous conf after ~1min

I think it can be nice to add preset operations like:

• list preset
• save current state
• delete preset
• export preset
• import preset

Now just choose what has to be in preset.

Nice idea for the two steps system.

I'd implement the preset stuff on top of the "main" api, since presets are quite complex to do correctly for cameras.

For example, you can have a preset that's camera dependant, and an another that is operator dependant (some cameraman have their habits, and they want to be able to take their favourite settings to the camera they are using, although we are probably far from that :-))