Create an API
Closed, ResolvedPublic


I'd like to create an API for the Beta. After one day of use of the Alpha, some auto documented stuff would be really of use.

My plan is as follow :

  • use php
  • one feature = one class = one file
  • use php reflection api to autogenerate a list of functions, documentation, properties that can be read / write
  • create a command line interface as well (ala drupal drush)
  • create a rest interface to this api
  • create a web front end to at least have a list of all the functions and properties, and a way to get / set all

The idea is to create an api that make sense (on the user side) without being polluted by camera specific (& temporary) quirks and implement it on the camera side, one feature at a time. So, even if we don't have iso setting for now, provide the api already and do our best to implement/enhance it in an iterative way. (what will iso be at the end? Analog gain? Digital gain? A mix of both? We can already provide the feature and implement it basically first, better after).

This could be part of the workshop we'll be doing soon. Any thoughts?

Related Objects

philippej updated the task description. (Show Details)
philippej raised the priority of this task from to Needs Triage.
philippej claimed this task.
philippej added a project: AXIOM Beta Software.
philippej added a subscriber: philippej.
philippej updated the task description. (Show Details)Jan 13 2015, 9:34 AM
philippej triaged this task as Normal priority.Feb 11 2015, 9:34 AM

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 :

This looks like a nice and lean alternative to symphony :

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 ( 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 :-))

anuejn closed this task as Resolved.Nov 5 2017, 10:10 PM
anuejn added a subscriber: anuejn.

Closed in favour of T757. If this is wrong, just reopen this task.