Grundsatzfragen

[enertegus]

Hallo,
ich hätte da mal ein paar Grundsatzfragen, die völlig blutdruckfrei mir erklärt werden müssten. Also bin ich mal frech und frag hier mal direkt:

1. Gibt es sowas wie ein Hello-World Beispiel, wo man das Prinzip vorgeführt bekommt?
2. Was genau sind denn die Systemanforderungen an Libs, Webserver etc.
3. Ich habe mich etwas rudimentär mit der Thematik "wie bekomme ich meine Daten auf der Visu aktualisiert" beschäftigt und sehe da aber auch bei html5 die Möglichkeit von Websockets - das macht ja Homecontrol so (wenn ich das recht verstehe). Was ist denn an den Websockets schlecht bzw. warum habt Ihr Euch dagegen entschieden, oder gehts darum gar nicht, oder macht ihr das auch so?

[Chris M.]

1. Gibt es sowas wie ein Hello-World Beispiel, wo man das Prinzip vorgeführt bekommt?

Am besten dürfte das Demo-WireGate unter demo.wiregate.de sein.
Und um zu sehen was da konkret passiert einen FireBug starten (so Du per Firefox surfst) oder die im Browser vorhandenen Debug-Möglichkeiten nutzen (Chrome, Opera).
Dort einfach mal einen Blick auf den Netzwerk-Verkehr.

Was Du da siehst kannst Du mit SourceForge.net: CometVisu/Protocol - Open Automation quervergleichen.

Im Grunde sind es zwei Vorgänge:

1. Zum Setup werden die Seiten basierend auf die visu_config von der tempalteengine.js (unter Verwendung der Widgets in structure_pure.js) aufgebaut. Dabei werden auch die GAs auf die gehört und geschrieben werden soll bekannt.
2. Die Kommunikation (und das ist ja das spannende) geht durch Aufruf der URL "l" für's Login. (Zur Zeit noch relativ Dummy, in Zukunft wäre eine Authentifizierung möglich)
   Und dann ist's schon im Produktiv-Betrieb. Per "r" werden die spannenden GAs gelesen. Gibt es noch keine, bleibt die Verbindung einfach offen, bis was kommt (-> COMET Pattern).
   Und Schreiben geht ganz einfach per "w".

2. Was genau sind denn die Systemanforderungen an Libs, Webserver etc.

Serverseitig?
Stand jetzt: ein aktueller eibd + eibwrite-cgi und eibread-cgi, diese passend bei einem Web-Server eingebunden. Für erweiterte Funktionaliät (Editor, RRD-Graphen) erwas mehr (PHP für ersteres, sprezielles rrd für zweites)

Bei einer "neu" Implementierung für ein neues System (was mag das wohl sein? ) müsste grundlegend neben dem statischen HTTP-Server dynamisch auf "r" und "w" reagiert werden. (Das "l" geht zur Zeit noch wunderbar statisch).
Die lassen sich ziemlich einfach erstellen, habe ich schon ein paar mal gemacht.

Das PHP für'n Editor sollte sich auch anders implementieren lassen (das ist im Grunde nur ein Nehme-Datei-entgegen-und-speichere-ab)

3. Ich habe mich etwas rudimentär mit der Thematik "wie bekomme ich meine Daten auf der Visu aktualisiert" beschäftigt und sehe da aber auch bei html5 die Möglichkeit von Websockets - das macht ja Homecontrol so (wenn ich das recht verstehe). Was ist denn an den Websockets schlecht bzw. warum habt Ihr Euch dagegen entschieden, oder gehts darum gar nicht, oder macht ihr das auch so?

Websockets sind für die Zukunft sicher spannend. Aber Stand jetzt (und v.a. Stand vor 1 1/2 Jahren als die CometVisu entstanden ist) nicht in der Breite nutzbar. Teilweise sind die aus Sicherheitsbedenken deaktiviert.
Das COMET Pattern nutzt dagegen nur ganz simples HTTP, das ist maximal kompatibel. Auch durch jegliche Firewall mit Proxy.

[swiss]

Da die Visualisierung selbst aus einem simplen xml besteht, könnte man auch auf den eingebauten Editor verzichten und z.B. selber ein Programm schreiben, mit dem man per Drag&Drop die Seite zusammen klicken kann. Wäre dann ala Experte beim HS. Dann kommt man sogar ganz ohne PHP aus.

Möglichkeiten gibt's da viele

[makki]

Ergänzend, mit anderen technischen Details:
- man braucht dazu einen nach RFC "funktionierenden" Webserver der CGI's ausführen kann, lighttpd genügt völlig, so crap wie uhttp nicht (siehe: RFC)
- das Frontend ist der Browser, egal, derzeit alles ausser IE (primär IMHO weil sich kein Pate mit "Liebe" für diese Sicherheitslücke findet, es ginge sicher)
- einen eibd (irgendwo) und die libeibclient zum erstellen der CGI's, dann aber bitte die GPL verstehen und den Sums freiwillig veröffentlichen, da wäre ich ehrlichgesagt recht empfindlich - oder das Backend eben mal schnell selber machen..
-> das läuft Stand heute wissentlich auch auf einem 20€ OpenWRT-Router mit 4MB Flash/32MB RAM wunderbar (inkl. eibd)

Es gibt dann noch zwei Ausnahmen: der Editor braucht eine Handvoll PHP's (die - mein Task - mal irgendwann CGI's in C werden, weil der massive overhead von Interpretern geht da eigentlich garnicht.. aufm WG ists wurscht aber..)
und das RRDtool für die Diagramme ist ein bisschen "gepatched" (dieser jedoch natürlich veröffentlicht!), auch meine Baustelle, kann man ja gerne selbst anders machen aber dito: wenn man es wiederverwendet will ich das in einem öffentlichen SVN oder was auch immer finden, sonst könnt ich unharmonisch werden oder gar Puls&Blut bekommen

Makki

[enertegus]

dann aber bitte die GPL verstehen und den Sums freiwillig veröffentlichen da wäre ich ehrlichgesagt recht empfindlich - oder das Backend eben mal schnell selber machen..

Das ist ja gerade die Frage, wo bzw. wie das Backend aussehen müsste, um mal bei dem IT Begriff zu bleiben...
Wenn Ihr "nur" einen Browser nutzt, wie erfolgt dann die Kommunkation? Per PHP Socket? Sorry dass meine Fragen wohl etwas Anfängerhaft sind, aber ich wills halt mal durchdringen.
P.S. GPL versteh ich schon, ich denke da braucht es noch nicht mal einen Zeigefinger.

[Chris M.]

Das ist ja gerade die Frage, wo bzw. wie das Backend aussehen müsste, um mal bei dem IT Begriff zu bleiben...
Wenn Ihr "nur" einen Browser nutzt, wie erfolgt dann die Kommunkation? Per PHP Socket?

Das Backend kann man getrennt vom der ganzen Client-Seite im Browser betrachten. Da kann man auch das Backend neu und in Closed-Source implementieren und trotzdem die Client-Seite im GPL verwenden.
Wichtig ist da nur, dass das Protokoll (Link s.o.) eingehalten wird.

Um erst mal zu starten muss im Backend (irgend)ein Web-Server laufen der statische Seiten ausliefern kann, so wie die Aufrufe von "r" und "w" (d.h. URLs wie http://1.2.3.4/cgi-bin/r und http://1.2.3.4/cgi-bin/w) so umbiegt, dass das Backend dynamisch darauf reagieren kann (das /cgi-bin/ da drinnen ist konfigurierbar.).
Die URL-Parameter dafür und die vom Backend erwarteten Antworten sind im Protokoll spezifiziert.

Die Funktionen hinter diesen beiden URLs ist auch überschaubar - die habe ich bereits min. 2x für unterschiedliche Anwendungen implementiert (jeweils ohne eibd Unterstützung). Ein mal in PHP, das andere mal in Python. Makki hat's in C (nämlich die eibread-cgi und eibwrite-cgi) geschrieben.
Andere Sprachen sind genau so einfach möglich - wichtig ist halt nur die Einbindung in den Web-Server.

[enertegus]

Andere Sprachen sind genau so einfach möglich - wichtig ist halt nur die Einbindung in den Web-Server.

Läuft das über eine Socketverbindung?

[netzkind]

Läuft das über eine Socketverbindung?

Ich bin mir unschlüssig ob ich die Frage richtig verstehe, aber hier mal der Versuch einer Antwort:

Der Client kommuniziert mit dem Server über eine regulären HTTP-GET-Request, den der Server so lange idlen lässt bis er eine Antwort hat (oder bis Timeout). Der Client stellt anschließend einfach eine neue Anfrage.

Der Editor kommuniziert mit dem Server über GET oder POST, je nachdem was er will.

Alle diese Requests werden per XMLHttpRequest gemacht, also "als AJAX-Requests".

Grüße,
Julian

PS:
Zur Kommunikation zwischen dem CGI und dem EIB, also Server-intern, kann ich nichts sagen.