Backend

[ctr]

Angenommen man würde eine neue Backend-Implementation (anstalle der eib-read/write-cgis oder OH) implementieren wollen, die kompatibel zu einem der beiden ist (um CV-seitig nichts anpassen zu müssen), wäre da eib-read/write-cgis mit long-polling oder OH mit SSE sinnvoller?

Ich denke technologisch wäre es eher SSE, aber welche Implikation hat es, wenn ich SSE ohne echtes OH nutzen würde? (außer das überall "OpenHab" als Backend zu konfigurieren ist, obwohl es gar kein OpenHab ist)

[Chris M.]

Ich kann über SSE und dessen Kompatibilität wenig sagen.
Die Long-Polling Verbindung hat sich über die Jahre aber als sehr stabil erwiesen, d.h. ich für mich habe keinen Grund davon weg zu gehen.

Was ich mir aber auch schon überlegt hatte, wäre ein Long Polling FastCGI-Backend zu schreiben, dass dann diese Vorteile hätte:

• Es müssen am Server nicht ständig neue Prozesse gestartet werden
• Die Verbindung könnte State-Full werden, was es ermöglichen würde, dass der CV-Client dem Server/Backend die relevanten Adressen nur 1x (pro Session) mitteilt und dadurch die Kommunikation in großen Installationen deutlich weniger Traffic erzeugt
  (Das CV Protokoll ist dafür bereits seit langem vorbereitet, nur implementiert ist es noch nicht)
• Evtl. komplett ohne knxd implementieren (oder das Caching selber übernehmen)

Ich bin das FastCGI Backend bisher noch nicht angegangen, da es eine niedrigere Prio hat (die bestehende Lösung ist ja stabil, wenn auch nicht optimal) und ich gerade mit einer höheren Prio an etwas ganz anderem dran, was das Thema hier in Teilen betrifft. Und auch da habe ich angefangen mir zu überlegen welche Transportart (Long Polling, SSE, Websockets, ...) die am besten geeignetste wäre . Noch habe ich keine Antwort, aber noch bin ich auch nicht so weit, dass ich die jetzt schon bräuchte.

[ctr]

Danke für die schnelle Rückmeldung!
Dann versuche ich mich mal an long-polling, scheint auf der von mir präferierten Plattform auch der einfachere Weg zu sein.

Nutzt die CV die in der Protokolldefinition erwähnten Filter eigtl schon?

[Chris M.]

Nein, da es das im aktuellen Backend nicht gibt (bzw. wegen des State-Less vom CGI nur mit Mehraufwand gehen würde) ist's im Client auf dem Browser auch noch nicht implementiert.
Das wäre aber genau das, was bei einer FastCGI Implementierung dann einfach möglich wäre.

Wenn das mal kommt, dann aber so, dass es auch mit dem aktuellen Backend noch möglich ist. Über das "l" lässt sich ja ganz gut steuern was mit der Backendkommunikation zu beachten ist, wie eben ob's schon Filter gibt oder nicht.