[PATCH] FHEMWEB: javascript: reconnect if longpoll connection is lost

[Matthias Gehre]

Hallo,

im Anhang einen Patch, der im longpoll Modus
"Connection lost, reconnecting in 5 seconds..."
anzeigt, falls fhemweb.js die Verbindung zum FHEM Server verliert.
Und reconnecten tut sie dann natürlich auch.

Das Design ist nicht überragend, da kann vielleicht jemand mit etwas mehr CSS Kenntnissen Hand anlegen.

Viele Grüße,
Matthias

[Matthias Gehre]

Hallo,

im Anhang der Patch aus Post 1 plus das Offenhalten der Verbindung.
D.h. es wird nicht nach jeder longpoll Antwort die Verbindung ab- und wieder aufgebaut,
sondern es wird versucht, die gleiche Verbindung offen zu halten.
Dies sollte dabei helfen, dass keine Longpoll Antworten mehr während des Ab- und Aufbaus
der Verbindung verloren gehen.

Viele Grüße,
Matthias

[Rudolf Koenig]

> im Anhang der Patch aus Post 1 plus das Offenhalten der Verbindung.

Funktioniert bei mir mit FF nicht: falls ich fhem abbreche, dann geraet FF in
eine Endlosschleife. Weiterhin gehoert styling ins stylesheet :)

[Matthias Gehre]

Danke für den Test,
der Fehler im angehängten Patch gefixt. Außerdem ist das Styling jetzt da, wo's hin soll :-)

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.

[Rudolf Koenig]

> der Fehler im angeh�ngten Patch gefixt. Au�erdem ist das Styling jetzt da,

> wo's hin soll :-)

Habs eingecheckt.

Etwas gibts trotzdem noch zu meckern :) FW_pollConn.responseText wird mit jedem
Statusaenderung etwa 200 Zeichen laenger, ist also ein Speicherloch: man
muesste die Verbindung nach etwa 1000 Aenderungen erneut aufbauen.

Btw.: weisst jemand, wieviele Bytes JS braucht um eine Buchstabe zu speichern?

[Matthias Gehre]

Ich hab mal an einer VM für Actionscript (Flash) mitgeschrieben (Lightspark), welches eine Variante von Javascript ist,
und dort brauchte ein Buchstabe genau ein Byte. Möglicherweise wirds aber auch in UTF-16 gespeichert, und dann wären's 2 Byte pro Buchstabe.

Am 26. November 2012 18:28 schrieb Rudolf Koenig <inf...@koeniglich.de>:

> der Fehler im angehängten Patch gefixt. Außerdem ist das Styling jetzt da,

> wo's hin soll :-)

Habs eingecheckt.

Etwas gibts trotzdem noch zu meckern :) FW_pollConn.responseText wird mit jedem
Statusaenderung etwa 200 Zeichen laenger, ist also ein Speicherloch: man
muesste die Verbindung nach etwa 1000 Aenderungen erneut aufbauen.

Btw.: weisst jemand, wieviele Bytes JS braucht um eine Buchstabe zu speichern?

[GerritSturm]

Richtig vermutet, JS speichert als UTF-16 braucht also 16Bit für jedes Zeichen.

Leider funktioniert das auslesen von responseText vor readyState 4 nicht in jedem Browser, prominente Beispiele Google Chrome oder InternetExplorer < 10.

Grundsätzlich finde ich die Idee aber Gut und zumindest in Chrome sollte es funktionieren wenn im Header "application/octet-stream" als Content-Type verwendet wird. Interessant wäre jetzt zu wissen wieviel Prozent der FHEM User einen IE < 10 benutzen.

Eventuell wäre es sinnvoll das verhalten beim eintreffen einer Nachricht per ATTR regeln zu lassen.

Danach sollte sich dann auch der Content-Type richten.

[Rudolf Koenig]

> Leider funktioniert das auslesen von responseText vor readyState 4 nicht in
> jedem Browser, prominente Beispiele Google Chrome oder InternetExplorer <
> 10.

Danke fuer den Hinweis. Hab gerade "Event Monitor" und longpoll geprueft mit
Firefox 16, Safari 6.0.2, Chrome 23 und IE8. FF und Safari funktionieren, wie
erwartet. Chrome erst ab eine content-laenge von 1k, IE gar nicht.
Funktioniert es denn mit Internet-Explorerer 10?

> in Chrome sollte es funktionieren wenn im Header "application/octet-stream"
> als Content-Type verwendet wird.

Habs gesetzt, damit funktionieren alle 3 in longpoll und in Event monitor,
IE 8 funktioniert weiterhin nicht. Habs eingecheckt, bin auf Nebeneffekte
gespannt.


> Interessant w�re jetzt zu wissen wieviel Prozent der FHEM User einen IE < 10
> benutzen.

Das wuerde mich auch interessieren, meine Entscheidungen aber nicht
beeinflussen :)

[GerritSturm]

Funktioniert es denn mit Internet-Explorerer 10? 

Jupp ohne zu bocken, war auch erstaunt.  

Habs gesetzt, damit funktionieren alle 3 in longpoll und in Event monitor,
IE 8 funktioniert weiterhin nicht. Habs eingecheckt, bin auf Nebeneffekte
gespannt.

Die könnten natürlich auftreten, normalerweise sollte laut Spezifikation bei readyState = 3 || 4 die bisher Empfangenen Daten auf jeden Fall im responseText stehen, warum Chrome bei ContentType:text/* responseText erst nach überschreiten von 1kb empfangener Daten bereitstellt ist mir auch ein Rätsel.

> Interessant w�re jetzt zu wissen wieviel Prozent der FHEM User einen IE < 10

> benutzen.

Das wuerde mich auch interessieren, meine Entscheidungen aber nicht
beeinflussen :)

 

Du hast natürlich recht, ich sehe das ganze wahrscheinlich von Berufswegen her aus einem anderem Standpunkt ;)

Persönlich finde ich die jetzige Lösung auch eleganter.