[vz-dev] API

[Steffen Vogel]

Hello List,

i'm currently working on the new backend implementation as Justin
mentioned. Some weeks ago, i completely took Justins code aside and
started with a new object oriented backend. Its based on the
Model-View-Controller pattern and is implemented with PHP 5.

After a week i realized that i spent 70% of my time on the database
abstraction and the object relational mapper.
So i kicked the DAL and ORM out of my code.
Now im currently using doctrine [1] which is a fine library which will
help us a lot.

> what's coming up?
> not only do we want to replace the code, but we'll also do this:
> - split the code into a "backend" and a "frontend"
>   - backend:
>     all the code that is not being accessed directly (i.e. works in the background, much like a db wrapper) is what we call the "backend"
>     the backend is contacted by the the controller (resp. whatever counter device we might be using) and by the "frontend"
>   - frontend:
>     all the code that is being used for the visualization (i.e. the code the user might get to see) is called the "frontend"
>     at present flo is working on a new browser visualization; although the frontend might also be code that feeds a fnordlicht [1] - much like a wattson [2] or a chumby [3] for a 24-7-in-home-visualization device that let's you know "en passent" what the current time^power consumption is
> Steffen created a visual overview: http://static.steffenvogel.de/wp-content/uploads/2010/07/overview.png

At the moment, i'm soldering my 10 fnordlicht-minis ;) I'm curious to
see them in action with volkszaehler.org/ethersex :)

> For a start some questions:
> - what parameters do we need for the two APIs? (they will probably differ somewhat)
> - how shall we document the current state of discussion? I think http://de.volkszaehler.wikia.com/wiki/Entwicklung/API would be the perfect place, wouldn't it?

Some weeks ago, i talked with flo about the API. Here's our first draft:
http://de.volkszaehler.wikia.com/wiki/Entwicklung/API/Referenz

Unfortunately, i hadn't enough time to take a look on Barts API.
Nevertheless, i think we could take Barts JSON Frontend API as an model
for our API.

> One basic concept is going to change in that transition, BTW: so far we're logging every single request which was easy to implement on the controller side but not exactly brilliant and causing a lot of headaches. The new concept would be:
> - define a resolution on the controller end (e.g. 1 minute, 15 minutes)
> - fire a request only at that interval, including a "count" parameter (in case there was something happening in the last interval)
> - the "count" (or whatevever we might be calling it) would be an absolute reading, not the number of pulses for the last interval; that makes the setup more robust against request loss

Now you finally convinced me ;) Especially the last point is quite
important. How do you think to reset the controller (absolute value =
0). And how do we want to save this value (EEPROM vs. RAM?).

Regards, Steffen

[1] http://www.doctrine-project.org/

-- 
Steffen Vogel
Roonstraße 106
Köln

Cell: +49 (176) 96978528
Web: http://www.steffenvogel.de
Mail & MSN: info at steffenvogel.de
ICQ: 236033