cometvisu-client.js überschreiben ohne hardcodierten UrlPrefix?

[jolt]

Ja vielleicht verstehe ich wirklich nicht was dein Vorschlag ist. Du wolltest backend doch deprecaten und durch backend_url ersetzen. Insofern wäre es nur ehrlich wenn in der Tabelle auf deiner Seite nicht backend= auftaucht sondern der neue Weg. Wobei ich jetzt nicht mal sagen könnte welche URL hier die richtige ist, weil das bisher ein Backend internes Detail war, was den User genau gar nicht interessieren musste.

Wenn man etwas deprecated dann entfernt man es auch irgendwann. Spätestens dann wird dein Vorschlag inkompatibel allem was ich aufgeführt habe. Oder du willst es nicht deprecaten + entfernen, dann sind es aber (dauerhaft) zwei Wege das Backend zu konfigurieren?

Wenn man jetzt nicht nur wie du es gemacht hast den XML Syntax betrachtet, dann ergeben sich auch Unterschiede im Editor und der Dokumentation. Da müssen dann nämlich beide Parameter dargestellt und erklärt werden. Und spätestens wenn du backend entfernst und openHAB User plötzlich eine URL eintragen müssen sind auch Bestandsuser betroffen. Dokumentation ist ohnehin eines der größten Baustellen der CV was Neueinsteiger anbelangt, ich finde wir sollten das eher verbessern und nicht noch komplizierter machen.

Damit sollte deine Frage warum es inkompatibel ist und für Verwirrung sorgt hinreichend beantwortet sein. Gegenfrage: Was stört dich denn an meinem Vorschlag. Ich habe hier mehrere Vorschläge gemacht um das Thema unter Berücksichtigung aller Interessen zu einer Einigung zu bringen. Du sagst selbst das die Unterschiede marginal sind, bewegst dich aber keinen Millimeter von deinem Vorschlag weg. Also scheint dich ja irgend etwas zu stören. Was denn genau? Ich lese immer nur warum meine Kritikpunkte aus der Sicht nicht valide sind, das bringt die Diskussion aber nicht voran. Meine Aufforderung nach einem Kompromissvorschlag hast du ebenfalls ignoriert.

Das ist natürlich nur meine Meinung und es steht dir frei dich davon beeinflussen zu lassen oder halt auch nicht. Weitere Meinungen sind hier gerne gesehen.

[tuxedo]

Zum Thema deprecated: Ja. Hier wäre aber zu definieren was das genau heisst:

* Abschaltung der Option mit Version x.y.z der CV --> Zöpfe abschneiden. Wer auf x.y.z upgraded muss den neuen Parameter benutzen
* Dokumentieren, dass man, wenn eine Angabe notwendig wird, nur noch den neuen Parameter zu benutzen hat, wohlgleich der alte auf unbestimmte Zeit Gültigkeit behält
* ...

Wobei ich jetzt nicht mal sagen könnte welche URL hier die richtige ist, weil das bisher ein Backend internes Detail war, was den User genau gar nicht interessieren musste.

Hatten wir nicht noch eben den konsens dass wenn die CV durch das Backend ausgeliefert wird, die URL über den HTTP-Header übermittelt wird? Insofern muss man gar nix angeben.

Wenn man etwas deprecated dann entfernt man es auch irgendwann. Spätestens dann wird dein Vorschlag inkompatibel allem was ich aufgeführt habe.

So ist das nunmal in der Software-Welt. Irgendwann gibt es inkompatibilitäten und man muss "aufrüsten". Bei einem Desktop-PC sehe ich diese notwendigkeit. Bei einer Visu die man einrichtet und die dann über Jahre ohne zutun läuft seh ich's nicht ganz so dringend. Und wenn es doch mal notwendig ist und man in die Inkompatibilität läuft, dann ist es wichtig dass es sehr einfach ist das System wieder ans laufen zu bekommen.
Da die meisten aber WG nutzen und man da eh nix konfigurieren muss oder etwas inkompatibel wird (weil man nirgendwo etwas angeben muss) stört es hier nicht.
Und wenn OH die Visu nach wie vor ausliefert, wird die Sache von ganz alleine kompatibel, da OH alles weitere über den HTTP-Header managed (bzw. managen könnte/wird/...).

Also betrifft es nur die Backends die nicht WG heissen, die nicht OH1/2 heissen und die zuvor eine Konfiguration im Stil backend="meinbackend" hatten. Aber da es hier keine gibt, gibt es gar kein Problem.

Wenn man jetzt nicht nur wie du es gemacht hast den XML Syntax betrachtet, dann ergeben sich auch Unterschiede im Editor und der Dokumentation. Da müssen dann nämlich beide Parameter dargestellt und erklärt werden.

Korrekt. Wobei auch deine Konstellation konsequenter Weise im Editor nachgezogen und dokumentiert werden müsste/sollte. Oder willst du das als "hidden feature" laufen lassen?
Ergo: Kein Vorteil deiner Variante gegenüber meiner.

Und spätestens wenn du backend entfernst und openHAB User plötzlich eine URL eintragen müssen sind auch Bestandsuser betroffen.

Wieder zurück zum konsens dass das backend, das die Visu ausliefert das im HTTP-Header regeln kann. Der Parameter darf dann also erst wegfallen, wenn das letzte Backend, welches die Visu selbst ausliefert, das mit dem HTTP-Header kann. Aber das sollte ja kein Problem sein.

Dokumentation ist ohnehin eines der größten Baustellen der CV was Neueinsteiger anbelangt, ich finde wir sollten das eher verbessern und nicht noch komplizierter machen.

Wo bitte ist meine Variante "kompliziert"? Streng genommen müsste, bis zum abschalten des backend= Parameters, gar nix für den Neueinsteiger dokumentiert sein, weil sich für den nix ändert (außer dass der Parameter früher oder später für ihn überflüssig wird wenn OH den HTTP-Header ergänzt hat).

Damit sollte deine Frage warum es inkompatibel ist und für Verwirrung sorgt hinreichend beantwortet sein.

Und ich habe aufgezeigt dass nix inkompatibel wird, sofern die Sache mit dem HTTP-Header in OH implementiert wird, welches selbst völlig transparent und kompatibel zum bisherigen ist.

Gegenfrage: Was stört dich denn an meinem Vorschlag.

Das erweitern des bisherigen Parameters macht dessen Syntax und Semantik komplexer, da zwei Dinge in einem Parameter untergebracht sind. Mein Ansatz stellt klar: Es geht um die backend_url.

Ich habe hier mehrere Vorschläge gemacht um das Thema unter Berücksichtigung aller Interessen zu einer Einigung zu bringen. Du sagst selbst das die Unterschiede marginal sind, bewegst dich aber keinen Millimeter von deinem Vorschlag weg. Also scheint dich ja irgend etwas zu stören. Was denn genau?

Ach, hab ich wen in meiner Argumentation übersehen/vergessen? Wer kommt denn mit meiner Lösung schlechter weg als mit deiner?
Beide Lösungen sind valide. Was mich stört ist die "verkomplizierung" des bisherigen Parameters. Aber wenn die deutliche Mehrheit sich für deine Variante begeistert... Demokratie. Dem beuge ich mich. Bis dahin bin ich der Meinung dass mein Vorschlag einfacher und klarer ist.

Weitere Meinungen sind hier gerne gesehen.

Ich bitte ausdrücklichst darum. Vielleicht gibt's ja noch einen dritten, viel besseren Vorschlag.

[Chris M.]

Nur der Vollständigkeit halber, für die weitere Disukssion nicht weiter relevant:

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

Das war umgedreht: das Wiregate hat das Default-Setup verwendet

Nun zum spannenderen:
Die Idee im Login-Response (dem "l") die Config zu senden finde ich sehr gut und das ist die Lösung für Plug&Play.
Es gibt da nur ein Problem: je nach Server-Konfiguration mag das nicht immer im gleichen Pfad liegen.

Die Lösung könnte sein, dass ohne "optionalen Backend URL Parameter" die CV auf dem Defaul-Pfad nachsieht. Und wenn dieser Parameter gesetzt ist, dann halt dort.
=> Auf dem WireGate würde sich nichts ändern
=> Auf anderen Servern die sich vom Pfad gleich verhalten würde der Out-of-the-Box funktionieren
=> Nur auf speziellen Setups (z.B. CV-Web-Server unter Port 80 und das Backend auf Port 8080 (*)) würde man den Parameter setzten müssen, den könnte man aber leicht im Handbuch für dieses Backend/Server-Gespann beschreiben

--
(*) Ich weiß gerade nicht, ob "unterschiedliche Server" für Web und Backend überhaupt funktioniert, oder ob da nicht ein JavaScript Sicherheitsmechanismus dazwischen funkt. Könne evtl. bei AJAX/COMET und SSE unterschiedlich sein

[NetFritz]

Hallo
Wenn man OH als Backend eingestellt hat kann dann noch KNX-Telegramme ohne OH empfangen?
Gruß NetFritz

[jolt]

Hallo
Wenn man OH als Backend eingestellt hat kann dann noch KNX-Telegramme ohne OH empfangen?
Gruß NetFritz

Nein, das geht dann nur noch über OH.

[jolt]

So ist das nunmal in der Software-Welt. Irgendwann gibt es inkompatibilitäten und man muss "aufrüsten".

Richtig, bin ich bei dir, aber halt nur wenn das signifikante Vorteile bringt. Die sehe ich hier nicht. Den Vorteil eines neuen Parameters mit der etwas klareren Semantik sehe ich sehr wohl, wenn man aber berücksichtigt dass außer dir niemand diesen Parameter braucht, dann kann man die Nachteile den alten Parameter etwas aufzubohren wohl einfach in Kauf nehmen. Du verstehst es, die anderen brauchen es nicht. Fertig. Problem gelöst.

Vielleicht gibt's ja noch einen dritten, viel besseren Vorschlag.

Da mein Vorschlag der Auto Configuration über HTTP Header ja offensichtlich gerade ein akzeptierter Teil der Verbesserungen geworden ist und unter der Annahme dass sich sowas auch für openHAB umsetzen lässt:

Wir lassen den XML Syntax wie er ist und definieren im Universal Client einen sauberen Mechanismus, mit dem man die URL über einen HTTP Response Header Eintrag überschreiben kann. Für dich wäre das eine Zeile in deiner Apache Config, für alle anderen entfällt jegliche Configuration. Finde ich die beste Lösung! Was denkst du?

[jolt]

Nur der Vollständigkeit halber, für die weitere Disukssion nicht weiter relevant:

Das war umgedreht: das Wiregate hat das Default-Setup verwendet

Alles klar

Die Lösung könnte sein, dass ohne "optionalen Backend URL Parameter" die CV auf dem Defaul-Pfad nachsieht. Und wenn dieser Parameter gesetzt ist, dann halt dort.

Genau so, zusätzlich ist die Idee über einen HTTP Response Header (beim Ausliefern der CV) bereits eine Backend URL mitzuschicken, die dann den Default Pfad überschreibt. Soweit Einigkeit. Die Frage ist noch: Brauchen wir zusätzlich einen Mechanismus um die URL im XML überschreiben zu können. Wenn ja in dem man einen neuen Parameter zur Backend Konfiguration einführt und den alten entfernt oder alternativ, in dem man den bestehenden Parameter um eine URL erweitert.

[peuter]

Ich finde die Ideen und Vorschläge die hier gerade diskutiert werden richtig klasse. Leider habe ich momentan nicht genügend Zeit um mich in ausreichendem Umfang mit dem Thema zu beschäftigen. Will aber trotzdem kurz meine Gedanken dazu äußern:

Die URL per HTTP-Header auszugeben finde ich sehr gut, da muss sich der Benutzer selbst um nichts kümmern, solche Lösungen sind immer erstrebenswert. Bei der Umsetzung dieser Lösung will ich mal kurz die verschiedenen Backends einzeln betrachten:

• Default: Da dies immer funktionieren soll, wenn nichts anderes angegeben wird, muss man hier auch nichts ändern
• openHAB 1: Da hier der interne Jetty-Server (welcher wiederum Teil eines Osgi-Bundles ist) die CV ausliefert, dürfte es schwierig werden, dort speziell einen zusätzlichen Header einzubauen, denn das CV-Backend kommt erst beim Login ins Spiel und dann ist es zu spät (die Protokoll erweiterung beim Login ist dagegen kein Problem). Ich will nicht ausschließen, dass es hier irgend einen Weg gibt, aber gehe erstmal vom Worst-Case aus. Daher müsste hier weiter der alte Backend-Parameter in der Config genutzt werden. Da der wegen der Abwärtskompabilität ja erhalten bleiben soll, sehe ich darin auch kein Problem (wird im Universal-Client wie schon gemacht halt hard-codiert)
• openHAB 2: Hier gibts ein eigenes Servlet, welches die CometVisu ausliefert, das jetzt schon selbst Configs generiert, PHP parsen kann usw. wird also kein Problem sein einen zusätzlichen Header einzubauen.
• Tuxedos backend (@tuxedo: hat das eigentlich einen Namen?): Hat er sich ja schon zu geäußert.

Was ich gerade nicht wirklich beurteilen kann ist der Sonderfall, der Leute, die die CometVisu von einem PHP-fähigen Webserver ausliefern lassen (z.B. Apache) und zum openHAB1-Backend proxien. Wie ist denn da das Setup überhaupt, bisher kann man ja auch keine extra URL fürs Backend definieren (außer man ändert den Sourcecode). Von daher braucht man dafür doch in Zukunft auch keinen extra Parameter, oder? Für openHAB2 ist das eh kein Thema, weil der selbst PHP kann, da braucht man das nicht mehr.

Um den aktuellen Stand der Diskussion nochmal zusammenzufassen:
Keine Änderungen an der Config-Syntax und der Rest wird über Erweiterungen der "neuen" Backends openHAB2 / tuxedos-Backend und des CometVisu-Protokolls erschlagen. Die Bestands-Backends (Default + openHAB1 funktionieren weiter wie früher, außer ich finde noch einen Weg den Jetty-Server zur Laufzeit entsprechend umzukonfigurieren).

Habe ich irgendwas vergessen / falsch verstanden?

[jolt]

Danke für dein Feedback!

Ja, openHAB hinter einem Proxy geht aktuell nur per Source Code Änderung. Ob das auf Grund von Cross Site Security Issues überhaupt geht kann ich nicht mal sicher sagen. Es ist aber kein Problem im Proxy eine zusätzliche Response Header Zeile einzufügen, daher sollte sich dieser Fall (sofern Cross Site geht) über die neue Methode abdecken lassen.

Wegen openHAB1 würde ich folgenden kleinen Hack vorschlagen:

 [FONT=Menlo][SIZE=11px]diff --git a/src/lib/templateengine.js b/src/lib/templateengine.js[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]index dffacc6..15f0844 100644[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]--- a/src/lib/templateengine.js[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]+++ b/src/lib/templateengine.js[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]@@ -149,7 +149,10 @@ $(document).ready(function() {[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]     noDemo: true,[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]     url : 'config/visu_config'+ (templateEngine.configSuffix ? '_' + templateEngine.configSuffix : '') + '.xml',[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]     cache : !templateEngine.forceReload,[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]-    success : function(xml) {[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]+    success : function(xml, textStatus, jqXHR) {[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]+      var serverVersion = jqXHR.getResponseHeader("Server");[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]+      var isOpenHAB = serverVersion == null ? false : serverVersion.lastIndexOf("Jetty", 0) === 0;[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]+      console.log(isOpenHAB);[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]       if (!xml || !xml.documentElement || xml.getElementsByTagName( "parsererror" ).length) {[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]         configError("parsererror");[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]       }[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px] [/SIZE][/FONT]

Dann können wir den backend Parameter komplett entsorgen oder zumindest hinter einem Nerd Only Schalter verstecken

[peuter]

Wegen openHAB1 würde ich folgenden kleinen Hack vorschlagen:
...
Dann können wir den backend Parameter komplett entsorgen oder zumindest hinter einem Nerd Only Schalter verstecken

Kann ich mich nicht so recht mit anfreunden, weils wirklich ein Hack ist. Zu sagen Jetty-Server = openHAB ist mir ein bischen zu unpräzise, auch wenns in 99% der Fälle stimmen mag. Wer weiß was die Zukunft bringt und openHAB1 von openHAB2 zu unterscheiden geht damit nicht, da muss man dann schon wieder zusätzlich nach dem neuen Header suchen (den die aktuelle Version von openHAB2 noch garnicht liefert). Lass mich erstmal gucken obs keinen "richtigen" Weg für openHAB1 gibt, bevor wir zu solchen Hacks greifen ;-)

Was ich bei meinem letzten Post ganz vergessen habe. Wann soll der zusätzliche Header denn ausgeliefert werden? Bei Auslieferung der index.html + JS Dateien der CometVisu macht es keinen Sinn, weil es ja dann noch nicht ausgelesen werden kann. Meines Erachtens macht das nur Sinn bei Auslieferung einer visu_config*.xml. Denn da wirds ja dann auch gebraucht. Klar kann der Server das einfach immer mitliefern, an anderen Stellen wirds dann halt ignoriert, aber wenn wir für dieses neue Backend-Feature Anforderungen definieren + dokumentieren würde ich sagen, das das mit den Configs geliefert werden muss.

[tuxedo]

Die Frage ist noch: Brauchen wir zusätzlich einen Mechanismus um die URL im XML überschreiben zu können. Wenn ja in dem man einen neuen Parameter zur Backend Konfiguration einführt und den alten entfernt oder alternativ, in dem man den bestehenden Parameter um eine URL erweitert.

Wenn jemand den Thread nicht komplett verfolgt hat, liest sich das so als ob ein bisheriger Parameter zusammen mit dieser etwaigen Änderung spontan und sofort entfernt wird. Ich würde ihn auf jeden Fall aus kompatibilitätsgründen und damit man etwas Zeit hat für die Umstellung noch eine weile Unterstützen.

• Tuxedos backend (@tuxedo: hat das eigentlich einen Namen?): Hat er sich ja schon zu geäußert.

Hat bis jetzt einen "Arbeitsnamen": CV Backend Plugin für KnxAutomationDaemon ;-) nennen wir's einfach nur kurz "kad".

Bzgl. des HTTP-Response-Headers: Ich bin gerade am schauen ob man das nicht noch in die Apache/Lighttpd Konfiguration eintüten kann. Dann wäre der Parameter komplett überflüssig. Bin mir allerdings noch nicht sicher ob die gängigen Webserver das alle aus ihrer Konfiguration heraus können (bzw. hinzufügen können). Wäre aber super wenn das ginge.

Was ich gerade nicht wirklich beurteilen kann ist der Sonderfall, der Leute, die die CometVisu von einem PHP-fähigen Webserver ausliefern lassen (z.B. Apache) und zum openHAB1-Backend proxien. Wie ist denn da das Setup überhaupt, bisher kann man ja auch keine extra URL fürs Backend definieren (außer man ändert den Sourcecode).

Man kann den Proxy doch aber so einstellen, dass die URL der "hardcodierten" entspricht? Hatte das glaub mal probiert weil ich den Editor auch mitnutzen wollte und mir das alleinige ausliefern der CV über OH1 irgendwie zu doof war.
Aber das ist wohl eher ein Spezial-Nerd-Fall.

Ja, openHAB hinter einem Proxy geht aktuell nur per Source Code Änderung.

Bist du dir da sicher? Meine ich hätte das schonmal erfolgreich probiert. Ist aber länger her.Könnte mich also irren.

Kann ich mich nicht so recht mit anfreunden, weils wirklich ein Hack ist.

Hacks are evil ;-)

Bei der ganzen Header-Auslieferei (ja, ich weiß, es gibt nicht soooo viele Backends und auf einzelschicksale muss man ggf. nicht so viel Rücksicht nehmen, aber die CV erhebt ja doch irgendwie den Anspruch universal zu sein, oder?):

Gesetz dem Fall es ist schwierig bis unmöglich für Nicht-OH-Backends in ihrem Apache/sonstwas den Header zu erweitern: Wie soll der Parameter in der CV config denn nu aussehen? Zwei Vorschläge wurden gemacht, einige Antworten sind gefolgt, aber keiner hat sich dazu geäußert.

[update]
Den Response-Header in Lighttpd anzupassen ist kein Problem: http://www.cyberciti.biz/faq/mod_set...ustom-headers/

Bei Apache ebenso kein großes Ding: http://alextsilverstein.com/programm...sponse-header/

Die Crux an der Geschichte: Die Angabe der URL ist nur verlagert. Wer kein Backend nutzt das die CV direkt ausliefert, wird hier so oder so irgendwo eine URL angeben müssen.
Mir persönlich ist es, nachdem ich geschaut habe dass das im Webserver machbar ist, schnuppe wo man es angibt.
Aber wenn man danach suchen müsste/wollte wo man es angibt, würde man es als unbedarfter Einsteiger mit Nerd-Genen eher in der CV als im Webserver suchen (Hintergrundgedanke: Der CV ist ein Client der sich zum Server verbindet. Und dem CV muss ich sagen wer der Server ist), und das könnte die "intuitive Konfiguration" etwas beeinträchtigen. Nur so als Randbemerkung.

[NetFritz]

Hallo

Zitat von NetFritz Beitrag anzeigen
Hallo
Wenn man OH als Backend eingestellt hat kann dann noch KNX-Telegramme ohne OH empfangen?
Gruß NetFritz
Nein, das geht dann nur noch über OH.

Sobald es mehre Backend gibt wir der Wunsch aufkommen mehre Backends in einer CV zu nutzen.
Das sollte man jetzt schon mal mit berücksichtigen.
Gruß NetFritz

[tuxedo]

Hallo

Sobald es mehre Backend gibt wir der Wunsch aufkommen mehre Backends in einer CV zu nutzen.
Das sollte man jetzt schon mal mit berücksichtigen.
Gruß NetFritz

Na bis jetzt sind die Backends ja grund verschieden in ihrer Struktur und verfolgen andere Ansätze, können aber alle ohne weiteren Umwege KNX.
Fällt dir ein Szenario ein in dem man z.B. knxd und OH gleichzeitig als Backend haben wollte?

und btw: Auch ohne mein Backend gibt es schon 3 an der Zahl. Und bisher hat sich glaub noch keiner gewünscht mehr als eines gleichzeitig zu nutzen.

[NetFritz]

Hallo
Da ja die CV auf längere Sicht ja eine universal Visu sein soll.
Könnte ja sein das man z.B OH oder IP-Symcon oder FHEM nutzt um seine Funksteckdosen zu bedienen und KNX-TP z.B. übers WG auch.
Da man bei OH bei "<address transform="OH:Nummer" mit angeben muss könnte die CV ja daraus erkennen das hier das OH-Backend genutzt werden muss.
Gruß NetFritz

[tuxedo]

Könnte ja sein das man z.B OH oder IP-Symcon oder FHEM nutzt um seine Funksteckdosen zu bedienen und KNX-TP z.B. übers WG auch.

?? Das WG ist doch mit dem USb-KNX-Adapter und der installierten Software ein KNX-IP-Router, oder? Wieso dann zum einen das WG als Backend nutzen und noch OH als Backend, wo doch OH prima das Wiregate als IP-Router nutzen kann. Ergo: OH als alleiniges Backend für die Visu reicht aus, nutzt dann halt das WG um auf den Bus zu kommen.

Würde für mich keinen Sinn machen da beides an die CV anzuschließen.

Theoretisch wäre es aber möglich die Situation über den Namespace "OH:" zu lösen.