Comet für GWT Evaluierung

Für eine Web-Application hab ich verschiedene Comet-Implementierungen für GWT ausprobiert.

Am tauglichsten stellte sich zunächst GWT-Comet heraus, das verschiedene Implementierungen für verschiedene Browser implementiert hat. Für IE-Browser hidden I-Frames, für Webkit-Browser EventSource usw …

Leider stellte sich heraus, dass es Probleme mit Opera-Browsern der Versionen 10.6 bis 11.5. Weiterhin funktioniert GWT-Comet nicht direkt mit dem IE9. Für zweiteres Problem gibt es einen Patch (der aber nicht in die Mainline aufgenommen wurde). Für erstes Problem hieß es:“Beim Opera-Browser wurde was kaputtprogrammiert und da gibts keine Lösung dafür“. In der tat hat sich das Problem ab Version 11.6 auch wieder von selbst behoben.

Aufgrund dieser Probleme habe ich mich nach Alternativen umgesehen und bin über ein Tutorial gestolpert, das „Gwt + Grizzly + Comet“ hieß. Der Verfasser hatte Teile vom RPC-Mechanismus von GWT nachgebaut und es „SimpleServlet“ genannt. Ich hab mir das angeschaut und es hat mir nicht gefallen. Er hat ja wirklich den ganzen Teil mit der Serialisierungspolicy übernommen … Kam mir etwas sehr redundant, nicht gepflegt und veraltet vor.

Was hab ich jetzt gemacht?

Ich hab ein simples HTTP-Long-Polling selbst implementiert. Im Prinzip läuft das so, dass der Client eine Anfrage an den Server stellt, dieser einfach nicht antwortet. Bevor ein TCP-Timeout stattfindet, schickt er aber eine Antwort an den Client, worauf anschließend die Connection geschlossen wird. Der Client bekommt seine Antwort, ist zufrieden und stellt die Verbindung gleich wieder her. Muss eine Message an den Client gepushed werden, während der Client wartet, kriegt er (natürlich) sofort seine Antwort. Anschließend wird die Connection geschlossen und der Client muss die Verbindung neu aufbauen.

Dies ist nicht so elegant, wie die ganzen Streaming-Methoden, ist aber einfacher zu implementieren und funktioniert mit Sicherheit mit jedem Browser.

Ein paar Dinge muss man aber dafür in Kauf nehmen:
– es gibt das Verbindungslimit für Browser, nach dem jeder Browser nur maximal 2 Verbindungen mit einer subdomain (nicht host!) aufbauen kann. Eine dieser Verbindungen ist schon belegt, d.h. statischen Content wie Bilder sollte man über eine andere Subdomain ausliefern.
– Mit dem Standard RPC-Mechanismus von GWT und den Cross-Domain-Beschränkungen kann der Long-Polling-Channel nicht (zuverlässig!) auf eine andere Subdomain gelegt werden. Manche Browser würden das gestatten, die meisten aber nicht.
– Long-Polling kann dazu führen, dass es so aussieht, als würde der Browser nie mit dem Laden fertig werden. Dies kann z.B. an einem Text „loading …“ oder einem Spinner erkennbar sein. Eventuell wirkt das irritierend.

Trotzdem scheint mir die Long-Polling-Lösung erstmal die allgemein besser unterstützte Lösung zu sein. Sie lässt sich mit GWT-Mittel ohne zusätzliche Libraries oder Änderungen direkt umsetzen und funktioniert garantiert.