cometvisu-client.js überschreiben ohne hardcodierten UrlPrefix?

[tuxedo]

Hallo zusammen,

im Rahmen meiner Backend-Implementierung und der Anpassung auf "Server-Sent Events" (kurz SSE, https://en.wikipedia.org/wiki/Server-sent_events), bin ich auf ein Problem gestoßen, welches ich mit meinem begrenzen JS Wissen nicht lösen kann....

comet-visu-openhab.js kann ja schon SSE in den Grundzügen. ABER das ist fest gemünzt auf das UrlPrefix von OH.

function CometVisuOh(urlPrefix) {
    var thisVisu = this;
    this.urlPrefix = "/rest/cv/";
    this.eventSource = null; // the EventSource

Deshalb habe ich versucht das zu verallgemeinern:

function CometVisuOh(urlPrefix) {
    var thisVisu = this;
    this.urlPrefix = urlPrefix;
    this.eventSource = null; // the EventSource

Das funktioniert auch erstmal (sofern man in templateengine.js entsprechend den Konstruktor mit einem UrlPrefix füttert), aber ganz unten an Ende der File steht noch:

};
CometVisuOh.prototype = new CometVisu('/rest/cv/');
CometVisuOh.prototype.constructor = CometVisuOh;
CometVisuOh.prototype.update = function(json) {
};

  return CometVisuOh;
});

Hier hab ich kein Plan wie ich das dynamisch, basierend auf dem UrlPrefix-Wert aus dem Konstruktor von comet-visu-openhab.js gestalte.

[etwas offtopic]
Ich hab schon peuter angeschrieben und gefragt wie es mit dem Umbau/Ausbau von comet-visu-openhab.js in einen allgemeinen, SSE-tauglichen Client aussieht (OH-spezifisches steckt da eigentlich nicht drin). Warte noch auf Antwort.

Im worst-case schraube ich eine eigene, SSE-allgemeine Client-Implementierung (basierend auf comet-visu-openhab.js) zusammen. Aber auch da hab ich dann das Problem mit dem dynamischen UrlPrefix. Und eigentlich würde ich Code-Duplizierung vermeiden wollen.
[/etwas offtopic]

Hat hier jemand einen Vorschlag und kann mir weiter helfen?

Gruß
Alex

[peuter]

Ich hatte schonmal mit einem universal client angefangen. Details folgen heute abend wenn ich wieder zu Hause bin.

Zum spicken:
https://github.com/peuter/CometVisu/...rsal-client.js

[peuter]

So jetzt etwas ausführlicher:

Der oben verlinkte Universal-Client soll maximal flexibel konfigurierbar sein. Für ein neues Backend kann man das interne this.backends object einfach um einen zusätzlichen Eintrag erweitern (wäre später eventuell sinnvoll das irgendwie auszulagern, aber fürs erste sollte das reichen. Die dort vorhandenen Beispiele sind hoffentlich selbsterklärend genug um zu zeigen was man da wie konfigurieren kann.

tuxedo
Am besten Du mach einen Fork von meinem Branch und guckst mal ob das mit Deinem Backend nach entsprechender Konfiguration funktioniert, bzw. ob was fehlt oder nicht funktioniert. Dann können wir das in dem Branch weiterentwickeln.

Jeder andere ist natürlich auch herzlich zum testen eingeladen, v.a. auch mit dem default Backend, da ich erstmal nur die openHAB Backends getestet habe. Fehler, Anmerkungen & Verbesserungsvorschläge sind immer willkommen.

[tuxedo]

Hi Tobias,

kannst du noch kurz erläutern wo der universal-client instantiiert/erzeugt wird? Oder ist der Teil noch ncith "angeschlossen".
Wenn ich das richtig sehe, dann erbt der universal-client nicht vom bestehenden CometVisu-Client, sondern ist eine verbesserte Kopie dessen, oder? Damit wäre auch meine obige Frage bzgl. des dynamischen UrlPräfixes am Ende des Scripts geklärt?!

Die Configs sind ja für default, OH und OH2 vordefiniert. Muss ein Alternatives Backend dann dort auch wieder als Config hardcodiert werden, oder soll das dynamisch, basierend auf backend="..." und einem weiteren Attribut transport="" in der visu-config.xml funktionieren?

[peuter]

kannst du noch kurz erläutern wo der universal-client instantiiert/erzeugt wird? Oder ist der Teil noch ncith "angeschlossen".

Der ersetzt die beiden bisherigen Clients (die sind nur noch im source um sich eventuell vergessene features ansehen zu können, werden aber selbst nicht mehr geladen) und ist auch der einzige client der benutzt wird, ist also "angeschlossen". Daum musst Du Dich nicht mehr kümmern.

Die Configs sind ja für default, OH und OH2 vordefiniert. Muss ein Alternatives Backend dann dort auch wieder als Config hardcodiert werden, oder soll das dynamisch, basierend auf backend="..." und einem weiteren Attribut transport="" in der visu-config.xml funktionieren?

Genau im aktuellen Stand muss dort für jedes Backend eine Config hardkodiert werden, in der visu-config muss dann nur noch das backend="" angegeben werden (wie bisher auch). In der dortigen hardcodierten backend-config kann man ja wesentlich mehr einstellen als nur backend + transport, das kann man garnicht alles in die visu-config.xml übertragen. Es werden ja sicherlich nicht täglich 10 neue Backends dazukommen, von daher halte ich das "hard-konfigurieren" der backends erstmal für eine vernünftige Lösung.

[tuxedo]

Auch wenn ständig neue Backend wohl eher die ausnahme sind, bin ich kein guter Freund von "Hardcodiert" um neues zu unterstützen, wenn doch die "Schnittstelle" recht klar definiert ist :-(

Wenn man das Attribut backend="" als Url-Prefix statt als "Auswahlname" nimmt und mit transport="" entscheidet ob "comet" oder "sse", dann hat man doch schon das allermeiste damit erschlagen, oder?

Das wäre auch mein Ansatz beim verallgemeinern von comet-visu-openhab.js gewesen... Hat zusätzlich den Vorteil, dass jeder frei in der Konfiguration des Webservers/Mod_Proxys ist was den Pfad hinter der URL angeht. Dass r=read, w=write etc... Das könnte man wohl voraussetzen/als gegeben ansehen.
Die zusätzliche if/else konstellation in templateengine.js würde dann auch wegfallen.

Im Universalclient kann man dann für den default und spezialfälle (OH) die spezialkonfiguration etwas hinterlegen, und für "Normalfälle" weiß man anhand des eingestellten backends ("wohin muss ich die Anfrage richten" --> backend = urlprefix) und des transports (comet, sse, ...) was zu tun ist. Universeller geht's denke ich nicht.

Sehe so beim drüber schauen sonst nur noch das Atmosphere-Zeugs das "speziell" ist.


Was hälst du davon?

[peuter]

Wenn dann wurde ich eine Mischung aus beidem vorschlagen. Für kompliziertere Sachen den vorhandenen hardcodierten Weg beibehalten und für einfachere Sachen 2 zusätzliche Parameter in die config.xml einbauen mit denen man die default-settings für urlPrefix und transport überschreiben kann. Wobei ich es aus Anwendersicht verwirrend finde den backend-Parameter für die urlPrefix zu mißbrauchen, daher lieber einen neuen einführen. Das wären dann jetzt:

backend = "default|openhab|openhab2" => für die auswahl der Hardkodierten backends
backend_prefix = "z.b. cgi-bin" => setzt den urlPrefix parameter fürs backend
backend_transport = "long-polling|sse" => Auswahl des Transport-Protokolls

Wobei man entweder nur den backend-parameter setzt oder die beiden anderen (die dann die Werte im default-backend überschreiben), alles zusammen zu nutzen macht aus meiner Sicht keinen Sinn.

Ich habe das mal fix in meinem Branch zusammengehackt, kanns aber gerade nicht testen. Am besten schaust Du Dir das mal an und probierst das aus. Kann aber gut sein, dass das noch nicht ganz rund funktioniert.

[tuxedo]

Wenn dann wurde ich eine Mischung aus beidem vorschlagen. Für kompliziertere Sachen den vorhandenen hardcodierten Weg beibehalten und für einfachere Sachen

Ja, sowas hab ich mir vorgestellt. Hintergrundgedanke war/ist: In der Doku zur CV ist ja das Protokoll beschrieben. "Eigentlich" ist das die einzige Schnittstelle an die sich ein Backendentwickler halten muss. Idealerweise muss man also in der CV nix anpassen/ändern damit ein neues Backend funktioniert. Soweit also die "ideale Welt".

Wobei ich es aus Anwendersicht verwirrend finde den backend-Parameter für die urlPrefix zu mißbrauchen, daher lieber einen neuen einführen.

Stimme ich dir zu. Würde dann aber vorschlagen in der Doku die zwei neuen als "den Standardweg" zu beschreiben und den "alten" backend-Parameter als "Altbestand" zu werten. Denke es wäre förderlich zukünftige Backens so zu gestalten, dass keine Änderung in der CV-Implementierung nötig ist und dies entsprechend in der Doku zu kommunizieren.

Wobei man entweder nur den backend-parameter setzt oder die beiden anderen (die dann die Werte im default-backend überschreiben), alles zusammen zu nutzen macht aus meiner Sicht keinen Sinn.

Stimme ich dir auch zu. Optional habe ich zwei Vorschläge:

1) backend_transport ist optional: Ist hier nix angegeben, wird vom "comet-style" ausgegangen. Nur wenn man vom Default abweicht/abweichen muss, wird die Angabe notwendig.
2) Ein evtl. konfigurationsärmerer Weg: Der Client macht einen Login am Backend. Das ist ja noch ziemlich Transport-Unabhängig. Die Login-Antwort transportiert nicht nur die Session-ID, sondern auch die Transport-Capabilities, ggf. mit Priorisierung seitens des Backends. Damit könnte sich der Client dann automatisch für die beste Option entscheiden. Nachteil: Man müsste die Protokollbeschreibung bzgl. der Login-Antwort um ein optionales Attribut "transport-capability" erweitern.

Ich habe das mal fix in meinem Branch zusammengehackt, kanns aber gerade nicht testen. Am besten schaust Du Dir das mal an und probierst das aus. Kann aber gut sein, dass das noch nicht ganz rund funktioniert.

Ich schau's mir an. Danke.

[peuter]

Stimme ich dir auch zu. Optional habe ich zwei Vorschläge:

1) backend_transport ist optional: Ist hier nix angegeben, wird vom "comet-style" ausgegangen. Nur wenn man vom Default abweicht/abweichen muss, wird die Angabe notwendig.

Das ist in der vorhandenen Lösung bereits so, beide Parameter sind optionial, wenn nicht gesetzt wird die Einstellungs vom Default-Backend genommen.

2) Ein evtl. konfigurationsärmerer Weg: Der Client macht einen Login am Backend. Das ist ja noch ziemlich Transport-Unabhängig. Die Login-Antwort transportiert nicht nur die Session-ID, sondern auch die Transport-Capabilities, ggf. mit Priorisierung seitens des Backends. Damit könnte sich der Client dann automatisch für die beste Option entscheiden. Nachteil: Man müsste die Protokollbeschreibung bzgl. der Login-Antwort um ein optionales Attribut "transport-capability" erweitern.

Die Idee gefällt mir sehr gut. Das Protokoll dahingehend erweitern, das Client + Backend alle spezifischen Einstellungen selbst aushandeln können (bzw. Backend teilt mit, CV handelt dementsprechend). Im Grunde kann dort das was da bisher im unirversal-client für die Backends hardcodiert wird komplett (bis auf die hooks, vermute ich) vom Backend per JSON beim Aufbau der Session (also beim Login) an die CV übermittelt werden. Wenn das Backend nichts sendet, werden die Default-Einstellungen genommen, somit funktioniert das Default-Backend weiterhin ohne das es angepasst werden muss und die openHAB1/2 + Deins können wir ja anpassen.

[jolt]

Ja bitte, macht so viel wie möglich ohne User Optionen. Wir haben ohnehin schon genug Einstellung die nirgendwo dokumentiert sind. Je weniger neue wir erschaffen desto einfach wird es für den User!

[tuxedo]

Die Idee gefällt mir sehr gut. Das Protokoll dahingehend erweitern, das Client + Backend alle spezifischen Einstellungen selbst aushandeln können (bzw. Backend teilt mit, CV handelt dementsprechend). Im Grunde kann dort das was da bisher im unirversal-client für die Backends hardcodiert wird komplett (bis auf die hooks, vermute ich) vom Backend per JSON beim Aufbau der Session (also beim Login) an die CV übermittelt werden. Wenn das Backend nichts sendet, werden die Default-Einstellungen genommen, somit funktioniert das Default-Backend weiterhin ohne das es angepasst werden muss und die openHAB1/2 + Deins können wir ja anpassen.

Dann würde sich im Idealfall die Konfiguration der CV in Bezug auf das Backend rein auf die Anzufragende URL/UrlPrefix beschränken.


Die Login-Antwort könnte dann so aussehen (erhebt keinen Anspruch auf korrekte Syntax, nur eben schnell von hand zusammengezimmert):

{
  "v":"MAJOR.MINOR.OTHER",
  "s":"SESSION"
  "c":{                   <-- c=configuration Neuere Backends sollten das liefern
       "backend":"BACKEND"       <-- Optional. Ein ideales Backend braucht keine Anpassung in der CV-Impementierung, von daher wäre die Backend-Identifikation nicht wirklich notwendig
       "transport":"TRANSPORT"     <-- Optional: per default wird hier von COMEt/Long-Polling ausgegangen. Weicht das Backend davon ab, sollte hier stehen was es benutzt, z.b. SSE
       <sonstiges>  <-- ggf. sonstiges das das Backend von sich gibt und interessant/wichtig für die CV ist?! Wüsste jetzt aber nix außen ggf. Infos für diagnostische Zwecke
  }
}

[Chris M.]

Das die Login-Antwort sagt wie der Server (von kommt diese Antwort schließlich) kommunizieren möchte finde ich gut.

Was das aber noch nicht löst (prinzipbedingt) ist wo der Server überhaupt angesprochen werden möchte. D.h. der URL Pfad. Denn das muss bekannt sein um "l" überhaupt aufrufen zu können.

[tuxedo]

Naja. Der urlprefix als alleinige Konfiguration wäre doch verschmerzbar, oder? Ansonsten müsste die CV im gleichen Pfad liegen wie das Backend. Und das könnte komplizierter zu konfigurieren sein.

[Chris M.]

Stimmt. Man kann ja Default annhemen und per optionalen Parameter in der Config übersteuern.

[tuxedo]

Brauch nochmal Hilfe in Sachen git:

Hab ja schon einen Fork des original CometVisu auf GH.

Aber wie komm ich jetzt zum universal-client Branch von Tobias?

Meine Idee wäre:

1) lokalen Branch erzeugen der sich so nennt wie der von Tobias
2) einen Fetch von Tobias' Branch in meinen eben erzeugten Branch

[update]

Ah, jetzt schnall ich's.. Fetch zieht nur die History und Branch-Info eines Repos.
Also erst ein Fetch der Infos, und dann ein Anlegen eines eigenen Branches basierend auf dem letzten commit aus dem universal-client branch ...