cometvisu-client.js überschreiben ohne hardcodierten UrlPrefix?

[jolt]

Du kannst über GitHub seinen Branch in deinen mergen:

https://github.com/tuxedo0801/CometV...iversal-client

[tuxedo]

Ah, stimmt. Über einen Pull geht das auch.

Gut, ich hab jetzt fetch benutzt und einen neuen Branch auf einem passenden Commit angelegt. Sollte fast auf's gleiche rauskommen.

Schau mir gerade den Code an. Dabei ist mir wieder etwas aufgefallen:

Die Sache mit dem UrlPrefix ist doch auch verwirrend, oder?
Spätestens wenn man OpenHAB einsetzt, hat man für die CV einen Apache/Lighttpd/... und das Backend kommt von einer OpenHAB Instanz (die auf Port 8080?) lauscht.

Man kann jetzt (wie ich bisher auch) z.b. Mod_Proxy einsetzen um das Backend hinter dem Webserver zu verstecken und über diesen erreichbar zu machen. Und jetzt kommt der UrlPrefix zum tragen:
Bei OH ist der quasi "vorgeschrieben"/vordefiniert.

Wenn ich jetzt den Login-Response um die Infos um was für ein Backend es sich handelt erweitere, dann muss die CV ja immer noch wissen WO das Backend zu erreichen ist.

Statt eines Prefixes: Wäre die komplette URL nicht intuitiver/einfacher anzugeben?

Wer nicht im Stande ist den Webserver entsprechend zu konfigurieren: Kein Problem: Einfach die komplette URL zum Backend angeben. Fertig.

Und wer gerne alles hinter einer Adresse/einem Port hat, der konfiguriert eben Mod_Proxy oder ähnliches. Aber selbst dann ist es ggf. einfacher/intuitiver die komplette URL statt eines relativen Prefixes anzugeben, oder?

Würde gerne unter diesem Gesichtspunkt den Universalclient für den "universalmodus" (also kein backen="oh" z.B. konfiguriert) so umbauen, dass man das Backend nur noch im Stil backend_url="http://myserverhost:myport/mybackend/" angeben muss.

Meinungen? Gegenvorschläge?

[jolt]

Die CV wird über openHAB ausgeliefert. Man braucht keinen extra Webserver. Daher genügt es backend=oh zu konfigurieren. Mehr muss man nicht einstellen. Wenn ich deinen Vorschlag richtig verstehe müsste man dann zusätzlich (oder stattdessen) in CV noch den Backend Pfad festlegen. Das wäre dann ein Rückschritt.

[tuxedo]

Nein, nicht zusätzlich. Stattdessen...

Also entweder der "bisherige, hardcodierte" Weg: backend="meinbackend"
Oder der "neue", bei dem alle Infos auf dem Login-Response kommen: backend_url="http://foo.bar/meinindividuellerbackendpfad/"

Also statt des Prefixes "/meinindividuellerbackendpfad/" (bei dem man auch noch wissen muss ob mit oder ohne "/") einfach die komplette URL.

Wobei ich im Code gerade sehe dass es wohl programmtechnisch keinen Unterschied macht ob ich den Request relativ (beginnend mit dem Prefix) oder absolut (komplette URL) absetze..?!

Meine Änderung ist hier einzusehen (nicht von der commit-meldung ignorieren lassen, war zu schnell beim klicken und hab die falsche Meldung übernommen):

https://github.com/tuxedo0801/CometV...8718e5c72c2bfd

Habs lokal getestet. Funktioniert ganz gut.

Ob nun Prefix oder URL sollte egal sein. Hab die Variable aber mal zur deutlichmaching dass auch URL geht von "urlPrefix" nach "url" umbenannt.

Änderungen am Backend:

Im Loginresponse muss sowas in der Art hier stehen:

{
"s":"46be989c-d9db-4111-95f7-7163281a471d",
"c":{
        "name":"KnxAutomationDaemon",
        "resources":{"read":"r","rrd":"rrdfetch","write":"w"},
        "transport":"sse"
},
"v":"0.0.1"}

Und in der Visu-Config:

<pages backend_url="/kad/" .....

oder eben eine komplette URL.

Beim handleSession() wird dann die Konfiguration gesucht und die lokale Einstellung this.config ggf. angepasst auf das was im response zu finden war.

[tuxedo]

Hatte noch einen Fehler drin: Das auswerten der config muss vor dem session-handling geschehen, sonst ist es schon zu spät. Habs angepasst.
Siehe:

https://github.com/tuxedo0801/CometV...iversal-client

Funktioniert ganz gut. Auch der Watchdog funktioniert mit dem Universal-Client und SSE besser bzw. überhaupt mal.

Muss jetzt nur noch schauen ob mein Xoro Megapad damit auch klar kommt (sollte eigentlich).

[update]

Komisch. Wenn ich in den Chrome Developer Tools den browser kurz "offline" stelle, dann bekommt er es hin die Verbindung wieder auf zu bauen. Starte hingegen das backend durch, bleibt die Verbindung tot und CV unternimmt keine regelmäßigen Versuche wieder eine verbindung her zu stellen... Muss mir doch den Code mal genauer ansehen.

[tuxedo]

So, der Reconnect funktioniert jetzt.

SSE macht von selbst nach 3sek einen Reconnect. Schlägt der fehl, wird ein erneuter Login probiert. Schlägt der Login an sich fehl, wird alle 3sek versucht einen Login durchzuführen bis es klappt.

Hab das bei mir jetzt mal verstärkt getestet. Auf dem Rechner mit Chrome ist das bis jetzt 100% zuverlässig. Auf dem Megapad in der Küche muss ich's noch testen. Bin aber zuversichtlich.

[tuxedo]

Da sich das ursprüngliche Thema etwas geändert hat, geht's nun hier weiter: https://knx-user-forum.de/forum/supp...niversalclient

[jolt]

Ich antworte mal hier, da es sich auf das alte Thema bezieht:

Nein, nicht zusätzlich. Stattdessen...

Also entweder der "bisherige, hardcodierte" Weg: backend="meinbackend"
Oder der "neue", bei dem alle Infos auf dem Login-Response kommen: backend_url="http://foo.bar/meinindividuellerbackendpfad/"

Also statt des Prefixes "/meinindividuellerbackendpfad/" (bei dem man auch noch wissen muss ob mit oder ohne "/") einfach die komplette URL.

Aus technischer Sicht kann man das so machen. ABER mir persönlich ist die Lösung viel zu technisch. Ob ich eine Url oder ein Backend eingebe ist im Grunde egal, ich muss beides wissen und beides verstehen. Aus User Sicht will ich gar nichts von beiden machen. Das sollten wir also anstreben und nicht Problem a durch Problem b ersetzen.

Ursprünglich musste man nichts machen, da der default dem Wiregate Setup entsprach. Erst mit dem OH Backend wurde eine zusätzliche Konfiguration nötig. Mit deinem Backend kommt jetzt eine weitere hinzu, die gleich noch einen weiteren Parameter definiert. Käse.

Ziel: Entpacken, index.html im Browser öffnen. Demo läuft. (Backend muss natürlich installiert sein).
Vorschlag: Wiregate wie bisher per default. openHAB1 sendet beim Ausliefern der Files im Header "Server: Jetty xxx". Das erkennen wir uns stellen OH1 Backend ein. Damit sollten schon mal 99.9% der User nichts einstellen müssen.

Ich kenne weder OH2 noch dein Backend genug um beurteilen zu können wie man das ggf. erkennen kann. Falls es etwas gibt, oder man etwas einbauen kann. Machen. Ansonsten kann man das dann über einen (nicht zwei) Parameter umstellen. Lasst uns nicht eine Million verschiedene Parameter erfinden, die niemand dokumentiert, niemand versteht etc.

Der Ansatz den Code zu generalisieren ist davon unbenommen top! Weiter machen!

Soviel zu meiner persönlichen Meinung.

[tuxedo]

Aus User Sicht will ich gar nichts von beiden machen.

Erinnert mich an klassische Manager-Denkweise ;-) Kann man auf der einen Seite nachvollziehen, aber der anderen Seite ist es aber oftmals auch ein "mit dem Kopf durch die Wand" gehabe (zumindest bei den Managern).

Ursprünglich musste man nichts machen, da der default dem Wiregate Setup entsprach.

Logo: Was soll man auch konfigurieren wenn es nur eine Konstellation gibt? Da kann man alles hartcodieren. --> Einfach für den User.

Die CV erhebt doch aber den Anspruch für sich, dass die "universell" ist, oder?

Erst mit dem OH Backend wurde eine zusätzliche Konfiguration nötig.

Auch logo... Irgendwie muss man ja unterscheiden ob man den Default-Weg oder OH Weg geht.

Mit deinem Backend kommt jetzt eine weitere hinzu, die gleich noch einen weiteren Parameter definiert. Käse.

Nein, kommt es nicht. Die Änderung um die es hier geht ist die Reduktion der Konfiguration auf einen Parameter:

Gibt man nix an: Default.
Gibt man "backend="oh"" an, dann der "alte hardcodtierte" Weg --> Alter Weg. Deprecated. Wird nur aus Abwärtskompatibilität bis auf weiteres weiter geführt.
Gibt man "backend_url="/foobar/"" an, dann das was angegeben wurde. --> Neuer, zu bevorzugender Weg für ein "nicht default backend".

Und wenn noch 200 Backends dazu kommen, dann bleibt es bei diesem einen Parameter: Der URL/dem Prefix/wie auch immer du es nennen magst.

Ziel: Entpacken, index.html im Browser öffnen. Demo läuft. (Backend muss natürlich installiert sein).

Sollte mit einem Default-Backend möglich sein. Aber entpacken und laufen lassen OHNE jegliche Konfiguration und dabei mit einem beliebigen Backend klarkommen wird nicht funktionieren.

Woher soll die Visu denn wissen wie und wo das Backend zu erreichen ist? Man kann natürlich "definieren" wie und wo die Login-URL zu erreichen sein soll. Dann wäre die CV "universell" und "konfigurationslos". Dafür ist man aber in der URL-Gestaltung seitens des Backends eingeschränkt.
Ich versteh auch nicht wo das Problem darin liegt für die prinzipielle gangbarkeit des Backends EINEN Parameter anzugeben. Um eine tolle CV-Visu zu haben, muss man hunderte Einstellungen (Adressen, DPTs, ...) vornehmen. Und dann soll der 0815 User mit einem URL/Prefix-Parameter überfordert sein?

"Auspacken, laufen lassen, geht" ist doch in keinem Fall möglich. Maximal eine Demo-Seite die die Widgets (ohne Funktion) zeigt. Aber dafür braucht man kein konfiguriertes Backend.

Vorschlag: Wiregate wie bisher per default.

Spricht nix dagegen. Wird wohl die meisten betreffen und sollte wohl auch so bleiben.

openHAB1 sendet beim Ausliefern der Files im Header "Server: Jetty xxx". Das erkennen wir uns stellen OH1 Backend ein. Damit sollten schon mal 99.9% der User nichts einstellen müssen.

Im Fall von OH geht das sicherlich, da die CV Seiten ja auch durch OH ausgeliefert werden. Prinzipiell hab ich kein Problem damit dass OH das so macht. Auf der anderen Seite bindet das die CV-Implementierung an ein ganz bestimmtes Verhalten von OH. Und das wiederum find ich nicht so toll.
Was wenn OH nur hinter einem Apache-Proxy laufen soll?

Ich kenne weder OH2 noch dein Backend genug um beurteilen zu können wie man das ggf. erkennen kann. Falls es etwas gibt, oder man etwas einbauen kann.

Mein Backend liefert nur sich selbst aus. Die CV wird von einem Webserver ausgeliefert. Und da sehe ich erstmal keine Option "etwas einzubauen" mit dem die Visu erraten kann wo das Backend zu erreichen ist. Außer vielleicht einen Default-Pfad den die Visu basierend auf dem Pfad von dem sie aufgerufen wird, versucht aufzurufen.

Bei OH2 wird glaub die Visu auch wieder vom Backend ausgeliefert. Aber auch hier gibt es sicherlich die Möglichkeit alles hinter einen Apache/Lighttpd zu verstecken.

Ansonsten kann man das dann über einen (nicht zwei) Parameter umstellen. Lasst uns nicht eine Million verschiedene Parameter erfinden, die niemand dokumentiert, niemand versteht etc.

Wo liest du denn immer was von mehreren Parametern? Oder war ich zu undeutlich?

Nochmal, 3 Möglichkeiten, und nur ein aktueller Parameter:

Möglichkeit 1: Nix konfiguriert: Default-Backend. Funktioniert "einfach so".
Möglichkeit 2: Der alte Weg über den "backend" Parameter. Funktioniert wie gewohnt, ist aber "deprecated"
Möglichkeit 3: Der neue Weg: Wenn man kein Default-Backend einsetzt: Ein einziger Parameter der den Prefix bzw. die URL des Backends beinhaltet. Damit werden alle aktuellen und künftigen Non-Default-Backends abgedeckt. Setzt halt voraus dass diese einen erweitertenb Login-Response anbieten in dem alles wichtige steht. Für den User ist das aber egal.

[jolt]

Ich habe dich schon verstanden. Uns unterscheidet halt der Umstand dass du versuchst jeden erdenklichen Corner Case zu berücksichtigen. Ich dagegen sage einfach 99.9% der User brauchen diese Komplexität schlicht nicht und für die mache ich das Leben so einfach wie möglich.

Wer seine CV über einen Reverse Proxy verteilen möchte, gerne! Dann muss er sich halt einlesen und ggf. fragen wir man das mit irgendwelchen Optionen die irgendwo dokumentiert sind machen kann. Oder auch mal eine Zeile am Code anpassen. Die 5 User weltweit, die dass betrifft, können damit umgehen oder haben schlicht Pech gehabt.

Die 500 User, die nicht mal wissen wie die Hello World Version der CV an den Start kommt, die liegen mir am Herzen. Und für die kämpfe ich (als Techniker und als Manager)

Wiregate ist schon automatisch und OH lässt sich hoffentlich automatisieren. Damit ist der backend Parameter nur noch für dich relevant. Wenn du jetzt noch eine Logik einbaust

if (backend[0] == '/')
backend_url = backend
else
< so wie bisher>

dann ist doch alles prima. Wir haben keinen neuen Parameter eingeführt. Niemand (ausser dir und den 5 Reverse Proxy Leuten) muss etwas einstellen. Dokumentation muss nirgendwo angepasst werden und alle sind glücklich.

[tuxedo]

Ich habe dich schon verstanden. Uns unterscheidet halt der Umstand dass du versuchst jeden erdenklichen Corner Case zu berücksichtigen.

Der Universalclient ist nicht auf meinem Mist gewachsen. Den hat peuter angefangen, auch ohne mich. Ich hab mich da nur dankend angehängt/angeschlossen.

Ich dagegen sage einfach 99.9% der User brauchen diese Komplexität schlicht nicht und für die mache ich das Leben so einfach wie möglich.

Es stand außer diskussion dass es für die 99,9% "anders" wird.

Wer seine CV über einen Reverse Proxy verteilen möchte, gerne! Dann muss er sich halt einlesen und ggf. fragen wir man das mit irgendwelchen Optionen die irgendwo dokumentiert sind machen kann. Oder auch mal eine Zeile am Code anpassen. Die 5 User weltweit, die dass betrifft, können damit umgehen oder haben schlicht Pech gehabt.

Und um genau die geht es beim Universal-Client.

Die 500 User, die nicht mal wissen wie die Hello World Version der CV an den Start kommt, die liegen mir am Herzen. Und für die kämpfe ich (als Techniker und als Manager)

Um die geht's doch gar nicht.

Wiregate ist schon automatisch und OH lässt sich hoffentlich automatisieren. Damit ist der backend Parameter nur noch für dich relevant. Wenn du jetzt noch eine Logik einbaust

Moment... Hier steht "CV universell machen" im Konflikt mit "CV automatisch für alle beiden Backends, außer meinem" machen.

Ich weiß nicht wie Tobias dazu steht, aber wir können auch den Universal-Client über den Haufen werfen und alle aktuellen und alle künftigen Fälle per Spezialimplementierung in der CV "automatisch konfigurierbar" machen. Der Code wird dadurch nicht besser. Aber immerhin hat der User einen Parameter gespart.

Wenn wirklich die allermeisten CV mit dem Wiregate nutzen, dann kann man die CV in der "Werkseinstellung" auch mit der Config für das WG-Backend ausliefern. Und die wenigen die dann davon abweichen geben halt ihre Backend-URL an.

if (backend[0] == '/')
backend_url = backend
else
< so wie bisher>

dann ist doch alles prima.

Meine Worte. Aber hier wäre wohl nur das Default-Backend berücksichtigt. OH müsste man explizit angeben. Hab ich aber kein Problem mit. Denn die 99.9% der User sind ja bereits glücklich.

Wir haben keinen neuen Parameter eingeführt. Niemand (ausser dir und den 5 Reverse Proxy Leuten) muss etwas einstellen. Dokumentation muss nirgendwo angepasst werden und alle sind glücklich.

"Wir haben keinen neuen Parameter eingeführt." würde ich ersetzen mit "wir haben alte Zöpfe abgeschnitten und alles auf einen sauber dokumentierten Parameter reduziert. Und jeder der 99.9% der Nutzer (WG) kann ohne Konfiguration das Default-Backend nutzen.".

Im Endeffekt sind wir aber mit diesem Thema DOCH im neuen Thread und nicht hier im alten. Denn es geht um den Universal-Client.

[jolt]

Der Universal Client ist die technische Implementierung unter der Haube. Da sind wir uns einig. Generalisieren und sharen.

Hier geht es um die Anbindung nach draußen (zum User). Das das sind zwei getrennte Themen, die aber zusammen aufgekommen sind.

Daher müssen wir auch den Universal Client nicht über den "Haufen werfen". In seiner Implementierung hat peuter z.B. die Anbindung nach extern gar nicht geändert sondern mit einem fixen Mapping intern angebunden. Genau so hätte ich das auch erst einmal gemacht.

Wenn wie von dir skizziert wirklich mal 200 Backends (mit relevanten Userzahlen) entstehen kann man das immer noch ändern.

Ich sehe auch nicht wo wir alte Zöpfe abschneiden, wir schaffen einen neuen Weg das Backend zu konfigurieren. Auch wenn du das nicht hören magst. Denn der alte Weg ist auch noch da. Sprich jetzt gibt's zwei. Das einer davon Legacy ist müssen wir den Usern erst mal erzählen, dokumentieren etc.

[tuxedo]

In seiner Implementierung hat peuter z.B. die Anbindung nach extern gar nicht geändert sondern mit einem fixen Mapping intern angebunden. Genau so hätte ich das auch erst einmal gemacht.

Eben, damit es erstmal abwärtskompatibel ist.
Dass das aber nicht DER Weg zu einer universellen Visu und deren Konfiguration ist, sollte eigentlich jedem hier klar sein.

Die Frage war dann: Wie macht man's besser, ohne es ganz anders zu machen?
Dann kam eben die Idee mit dem erweiterten Login-Response.
Und da waren wir uns glaub alle einig dass das eine gute Sache wäre, wenn man weniger konfigurieren müsste, oder?

Nun, für einen Login muss man aber erstmal wissen wohin man sich wenden muss.
Der alt-eingesessene CV User mit seinem WG muss nix ändern, da "abwärtskompatibilität".

Und der, der die Visu NEU installiert geht eben einen für die Zukunft einheitlichen Weg.

Ich sehe auch nicht wo wir alte Zöpfe abschneiden,

Na gut, nicht direkt abschneide, aber zumindest schon für "alt" erklärt und zum Abschneiden angekündigt.

wir schaffen einen neuen Weg das Backend zu konfigurieren.

Korrekt, unter vorläufiger beibehaltung des alten.

Auch wenn du das nicht hören magst.

Was soll das denn? Ich bin für alles offen.

Denn der alte Weg ist auch noch da. Sprich jetzt gibt's zwei. Das einer davon Legacy ist müssen wir den Usern erst mal erzählen, dokumentieren etc.

Und? Wo ist das Problem? Wieviele CV User beschäftigen sich nach 5 Jahre noch mit der Visu, wenn sie erstmal läuft?

Wo also ist das Problem mit "neuen" Usern einen "neuen" Weg zu gehen? So extrem viel "backend-relevante Doku" existiert nicht als dass das zu einer Mammutaufgabe werden würde.

Und zuguter letzt gibt's ja "nur zwei bekannte Backends". Eines davon deckt offenbar den Großteil der User ab (WG). Da hier per-se eine Default-Konfig existiert (egal wie die aussehen mag, man muss sie als WG User ja nicht anpassen, da default), interessiert es die nicht.
Von daher wären es nur ein paar OH User, und da wohl auch nur die noch sehr wenigen OH2 User (OH1 läuft ja noch mit abwärtskompatibilität mit dem alten Weg).

JETZT hätte man noch die Chance etwas zu ändern ohne dass es gleich verdammt viele betrifft. Deshalb würde ich JETZT die Chance nutzen.

[jolt]

Seufz, letzter Versuch:

Ich denke ich habe ausreichend aufgeführt warum ich glaube, dass die normalen User weder eine neue backend Option brauchen, noch wollen, noch haben sollten. Wenn man etwas ändern will dann eher die backend Option komplett optional zu machen und automatisch zu erkennen.

Anders als du sehe ich ein Riesenproblem darin bestehende Konfigurationen, Dokumentation, Beispiele, Foren Posts etc ungültig werden zu lassen, in dem man inkompatible Optionen einführt. Ob jetzt oder später ist dabei egal. Das macht man nur, wenn es nicht anders geht oder mit sonstigen Aufwänden verbunden ist. Die sehe ich hier nicht, oder wurden noch nicht dargelegt.

Im Sinne einer Lösung wäre es toll wenn du diese Argumente nicht einfach ausklammerst oder fragst wo das Problem ist. Das bringt uns nicht weiter. Super wäre ein konkreter Lösungsvorschlag, der obige und deine Wünsche berücksichtigt. Über den können wir dann gerne weiter diskutieren.

Unstrittig scheint bisher zu sein:

1. Das wir einen Universal Client einführen der SSE und Long Polling Code generalisiert und Backend unabhängig macht
2. Das wir das Login Protokoll erweitern, damit das Backend mitteilen kann ob SSE oder LP genutzt werden soll. Gff. können hier weitere Parameter ausgehandelt werden.

Korrekt soweit?

Offen ist also nur wie der Client die Login URL bekommt. Korrekt?

Mein Vorschlag (in Anlehnung meines Vorschlages von oben):

Wir erweitern den backend Parameter um folgenden Syntax:

backend=<backend>[,url=<url>]

<backend> kann dabei auto, oh oder oh2 sein.
<url> ist optional, fehlt die Angabe wird der default des Backends genommen, ist die Angabe da wird die URL des Backends überschrieben. Default URL des Auto Backends ist die Wiregate URL.

Ist der backend Parameter gar nicht angegeben, gilt implizit backend=auto. Verbindungstyp ist per default für oh2 SSE, für alle anderen LP, kann aber immer per login Information überschrieben werden.

Beispiele:

Wiregate: backend=auto (oder ganz weg lassen)
OH1: backend=oh
OH1 hinter Proxy: backend=oh,url=myproxy:4711/foo/cv
Tuxedo: backend=auto,url=myserver:1234/bar/cv

In einer weiteren Ausbaustufe sollten wir dann versuchen zu erkennen, dass die CV vom OH Server kommt und die default URL des auto Backends entsprechend anpassen. Dann können auch die OH1und OH2 Leute den backend Parameter auf auto stellen oder ganz entfernen, sofern sie keine speziell Setups ala Reverse Proxy haben.

[tuxedo]

*Seufz* (kann ich auch).

Ich denke ich habe ausreichend aufgeführt warum ich glaube,

hast du, ja. Aber es gibt ja hoffentlich noch mehr Meinungen dazu.

dass die normalen User weder eine neue backend Option brauchen

Dem neuen User ist es egal ob er a="xyz" oder b="def" hinschreiben muss. Und dem alten Nutzer ist es auch egal, solange er keinen Finger krumm machen muss.

, noch wollen

Woher weisst du das?

, noch haben sollten.

Sagt wer?

Anders als du sehe ich ein Riesenproblem darin bestehende Konfigurationen, Dokumentation, Beispiele, Foren Posts etc ungültig werden zu lassen, in dem man inkompatible Optionen einführt.

Mein Vorschlag beruht von vorne bis hinten darauf dass nix inkompatibel wird. ich glaube wir reden aneinander vorbei.

Im Sinne einer Lösung wäre es toll wenn du diese Argumente nicht einfach ausklammerst oder fragst wo das Problem ist.

Im Sinne einer Lösung wäre es toll, wenn du dich, statt den Vorschlag offenbar nicht 100% zu verstehen, stattdessen einen Gegenvorschlag machst (dazu komm ich gleich).

Unstrittig scheint bisher zu sein:

1. Das wir einen Universal Client einführen der SSE und Long Polling Code generalisiert und Backend unabhängig macht
2. Das wir das Login Protokoll erweitern, damit das Backend mitteilen kann ob SSE oder LP genutzt werden soll. Gff. können hier weitere Parameter ausgehandelt werden.

Korrekt soweit?

Korrekt.

Offen ist also nur wie der Client die Login URL bekommt. Korrekt?

Korrekt.

Wir erweitern den backend Parameter um folgenden Syntax:

backend=<backend>[,url=<url>]

Aha.

Beispiele:

Wiregate: backend=auto (oder ganz weg lassen)
OH1: backend=oh
OH1 hinter Proxy: backend=oh,url=myproxy:4711/foo/cv
Tuxedo: backend=auto,url=myserver:1234/bar/cv

Okay, dann stelle ich mal den direkten Vergleich zwischen deinem und meinem Vorschlag auf, und hoffentlich erscheint hier noch jemand der seine Meinung dazu kund tut.

	jolt	tuxedo
WG	backend="auto" (oder ganz weg lassen)	backend="auto" (oder ganz weg lassen)
OH1	backend="oh"	backend="oh"
OH1 hinter Proxy	backend="oh,url=myproxy:4711/foo/cv"	backend_url="myproxy:4711/foo/cv"
OH2	backend="oh2" (???)	backend="oh2"
Tuxedo, sowie alle künftigen Backends, egal ob vor oder hinter Proxy	backend="auto,url=myserver:1234/bar/cv"	backend_url="myserver:1234/bar/cv"

Die Unterschiede sind eigentlich marginal. Deine Idee verbastelt alles in einen Parameter, bzw erweitern deren Syntax.

Und ich hab für die URL einen neuen Parameter, der den bisherigen aber nicht braucht. Damit ist die Funktion der Parameter klar getrennt, ist einfach zu erklären und der Standarduser kommt damit überhaupt nicht in Berührung.

Und jetzt erklär mir bitte nochmal dass meine Lösung Inkompatibilitäten in der Konfiguration oder Probleme bei der Doku oder Verwirrungen bei den bisherigen Nutzern verursacht.

In einer weiteren Ausbaustufe sollten wir dann versuchen zu erkennen, dass die CV vom OH Server kommt und die default URL des auto Backends entsprechend anpassen. Dann können auch die OH1und OH2 Leute den backend Parameter auf auto stellen oder ganz entfernen, sofern sie keine speziell Setups ala Reverse Proxy haben.

Bin ich nach wie vor einverstanden. Wenn die CV durch das backend selbst ausgeliefert wird, kann die URL über HTTP-Header mitgeteilt werden. Sollte man dann aber auch möglichst allgemeingültig definieren.