[vz-dev] Neues Backend

[Justin Otherguy]

Moin,

(schicke diesen Faden, den ich off-List angezettelt habe, nun wieder dahin, wo er auch hingehört - on-list)

In die Diskussion selbst will ich im Moment mal gar nicht allzu tief eingreifen - ich gebe nur an ein paar Stellen meinen Senf dazu (...warum ist das eigentlich so?)

Am 30.05.2010 um 12:59 schrieb Steffen Vogel:

> Hi flo :)
> 
> Am Sonntag, den 30.05.2010, 12:37 +0200 schrieb Florian Ziegler:
>> Hallo Ihr beiden,
>> 
>> Ich denke, wir sollten erstmal definieren, was das Backend denn eigentlich 
>> machen soll. Ich verstehe das so:
>> Funktion 1:
>> 	Zur Installation Kanäle anlegen und verwalten. Macht bei mir 
>> channel_admin.php nur spartanisch aber tut.
>> 
>> Funktion 2:
>> 	Pulse in DB loggen. Das macht httplog.php doch schon ganz gut. Der Kern 
>> besteht da ja nur aus 5 Zeilen Code. Hier halte ich es nicht unbedingt für 
>> sinnvoll eine DB-Abstraktion einzuführen, das bläht den Code doch mehr auf, 
>> als das es ihn übersichtlicher macht. Wenn wir z.B. als DB mysql,pgsql und 
>> sqlite unterstützen, kommen einfach drei verschiedene 'db_connects' und 
>> 'INSERTS' untereinander, das werden keine 100 Zeilen Code und ist für Embedded 
>> Systeme auch ressourcenschonender als dafür extra ne Datenabstraktion zu 
>> laden.
>> 
>> Funktion 3:
>> 	Pulse unter Angabe des Zeitbereiches (von bis) und des 
>> Aufsummierungsintervalls aus DB lesen und als JSON an den Browser 
>> zurückschicken. Das macht bei mir smartmeter.json.php. Hier ist eine DB-
>> Abstraktion evtl. sinnvoller.
>> 
>> Alles andere würde ich komplett im JavaScript abwickeln. Bin der Meinung, dass 
>> das Backend nicht dafür verantwortlich ist, abhängig von der Displaygröße 
>> andere Daten zu liefern, das muss der Client erledigen.
>> Ob der Client die Daten dann per flot oder jqPlot ausgibt sollte dabei doch 
>> für das Backend keine Rolle spielen?!
>> Die Schnittstelle (also das JSON Format) können wir langfristig mit flukso 
>> absprechen und vereinheitlichen.
> 
> Ich dachte hier geht es um die Schnittstelle Controller -> Backend? Oder
> doch um Backend -> Browser?
> 
>> 
>> Bleibt es bei diesen drei Funktionen, bin ich der Meinung muss man das 
>> zumindest Im Moment nicht wie bei Steffen auf 25 Dateien verteilen.
> 
> Ja mit den Dateien habe ich es vielleicht etwas übertrieben. Das sind
> aber im Prinzip alle Dateien die man auch in Zukunft braucht. 
> 
> Im Grunde hast du ja recht mit diesen drei Aufgaben des Backends.
> Mal mit dem MVC Pattern ausgedrückt:
> 
> Model		=> Datenbank
> View		=> Browser (teils auch im Backend)
> Controller	=> Backend
> 
> Jedoch gehört für mich zum Backend auch noch eine gewisse
> Verwaltungsebene. Also das Verwalten von Gruppen/Usern, Zählern,
> Einstellungen (Zählerbeschreibungen, Auflösungen, Kosten etc).. Das
> Zurücksetzen der Zähler, generieren von Reports müsste auch im Backend
> gelöst werden.
> 
> Ich finde die Darstellung sollte im Browser laufen. Die Berechnung auf
> dem Backend (Min, max, avg, Statistiken etc.).
> Zu den Berechnung zähle ich auch das Aggregieren der Pulse.
> 
> Ich halte dich Strukturierung in Klassen für äußerst wichtig.
> Andere Ausgabeformen (SMS, auf dem Server gerenderte Graphen, Email,
> Benachrichtigungen etc.) müssen teils auch auf dem Server erzeugt
> werden.
> 
> Hier sollte man klar definierte Interfaces (wie auch bei den Zählern
> (include/classes/meter.php)) haben.

>> Wegen der Energieanzeige. Ich hab da mal im Frontend ein Balkendiagramm draus 
>> gemacht:
>> http://volkszaehler.f10-home.de/smartmeter.html
>> Info: Energie - Bereich: Jahr - Gruppierung: Monat - Kanäle addieren.
>> Ich denke jetzt wird klar, was ich damit meine. Alternativ kann man statt der 
>> Energie auch noch die Kosten pro Intervall mit angeben.

> was hältst du davon noch ne zweite Liste einzurichten?
> volkszaehler-dev, volkszaehler? Einmal für Anwender und einmal für
> Entwickler? Es sind ja bereits ein paar Installationsfragen aufgekommen.
die zweite Liste hatte ich als Option vorgesehen; wäre kein Problem (drum hat diese hier ja auch schon -dev anhängen); allerdings finde ich das noch zu früh:
- die Abonnenten wäre wohl die gleichen
- die Themen, die für Anwender relevant sind, fliessen sicher auf absehbare Zeit noch in die Entwicklung ein ("ah, stimmt, das ist aber eine gute Idee..." -> ...)

Finde also, dass wir uns das im Moment mal noch verkneifen sollten.

>>> Ja Strukturell hat sich einiges geändert. Z.B. referenzieren UUIDs keine
>>> User mehr. Bei mir hat jeder Zähler eine eigene UUID. Dann gibt es ein
>>> n-zu-n Mapping von Usern zu Zählern. Dadurch können mehrere User einen
>>> Zähler Betrachten.
>> 
>> ist das nicht genau das, was wir vermeiden wollen? also die Zuordnung eines 
>> Users zu einem Zähler? Oder was verstehst du unter User zu Zähler Mapping?
> 
> Naja es muss ja kein User sein. Ich denke nur dass wir alle Zähler
> möglichst getrennt verwalten sollten. Dann kann der Nutzer selber
> entscheiden welche Daten er zusammengefasst angezeigt bekommen will.
> 
> So kann z.B jeder User seinen eigenen Stromzähler haben.  Zwei Nachbarn
> können sich jedoch zb einen Temperatur Sensor teilen.
> 
> Oder in einer WG: es gibt einen Gesamtzähler den alle Bewohner sehen
> können.
> Jeder Bewohner hat dann für sein eigenes Zimmer nochmal einen eigenen.
> Hier eine Gruppierung auf Controller Ebene einzuführen (per UUID) finde
> ich nicht so gut. Das muss nicht immer der Realität entsprechen. Und man
> hat dadurch eine Begrenzung auf einen Controller.

z. Info: woher kommt die Zuordnung uuid - Controller überhaupt?

Ich hatte zwischenzeitlich auch mal die Idee, eine uuid pro Zähler zu verwenden, fand das dann aber unpraktisch, wenn ich zum Abrufen des Profils 3 uuids übergeben muss. Das können wir gerne hier auf der Liste diskutieren. Stellt sich auch hier die Frage, was dagegen spricht, beide Varianten vorzusehen. Die Auswirkungen auf die Serverseite wären m.E. gering: 
- Logging: wir würden den Parameter für den Kanal (bzw. Zähler) vorsehen; dieser könnte dann auch optional sein
- Auswertung: wir würden vorsehen, dass die einer uuid zugeordneten Zähler aus der DB ausgelesen werden; hat der Benutzer sich für 1:1 entschieden, hat diese Liste eben nur einen Eintrag für eine uuid


Gruss, J.