Das deutsche Python-Forum

mitsushiko: Ja, aber erst jetzt hab' ich's irgendwie verstanden.

Gibt es dabei irgendwelche Limitierungen*, z.B. kann diese Verbindung "unendlich lange" aufrecht erhalten werden?

Was genau macht Comet anders?

Gibt es bessere Ansätze? Scheinbar ja nicht ...


*) Ok, mal abgesehen davon, dass ich den Server hier abschießen muss und nicht mehr normal beenden kann.

Y0Gi hat geschrieben: Gibt es dabei irgendwelche Limitierungen*, z.B. kann diese Verbindung "unendlich lange" aufrecht erhalten werden?

Ja

Wäre cool, wenn sich noch mal jemand zur ursprünglichen Frage äußern könnte, wie ich jetzt daten an alle geöffneten http-clients broadcasten könnte

Broadcasten in dem Sinne kann es ja schon nicht sein, da du zu jedem Client einen eigenen Socket hast.

Ich würde versuchen, die WSGI-Callable nach dem eigentlichen XHTML-Dokument weitere Daten aus einem Iterable holen zu lassen, das allen Instanzen zur Verfügung steht, entsprechend thread-safe sein müsste und aus dem pro Request/Socket jedes Element nur einmal gelesen wird. Notfalls könnte man für die aktiven Client-Verbindungen eine Liste von ``Queue``-Objekten bereithalten (was dann aber z.B. einen separaten Thread erfordert) und jedes bei vorliegenden Daten füttern, die der Client sich abholt.

Jan.O hat geschrieben:

Y0Gi hat geschrieben: Gibt es dabei irgendwelche Limitierungen*, z.B. kann diese Verbindung "unendlich lange" aufrecht erhalten werden?

Ja

Dann kannst du sie mir ja auch kurz ausführen. Auch wenn (oder gerade weil) es etwas abgeschweift ist (oder so scheint), sollten wir das zu einem brauchbaren Ende bringen.

Davon ab hätte ich mich ohne die Ausführungen anhand deiner, naja, etwas abstrakt formulierten Problemstellung nicht in das hineinversetzen können, was du vorhast.

Das "ja" bezog sich auf den 2. Teil: Die verbindung kann "unendlich" lange aufrecht erhalten werden.

[strong]X[/strong]HTML streamen ist eine schlechte Idee weil ältere Browser XHTML Dokumente nur dann rendern können, wenn sie die komplett geladen haben. Zb Firefox 2.

Oh, gut zu wissen. Wonach richtet sich das denn? Dem Content-Type? Dem DOCTYPE? Dem Namespace?

mitsuhiko hat geschrieben:[strong]X[/strong]HTML streamen ist eine schlechte Idee weil ältere Browser XHTML Dokumente nur dann rendern können, wenn sie die komplett geladen haben. Zb Firefox 2.

Danke für den tipp! habe meine tests auch immer mit normalem html-code gemacht.

Y0Gi hat geschrieben:Oh, gut zu wissen. Wonach richtet sich das denn? Dem Content-Type? Dem DOCTYPE? Dem Namespace?

Nach dem Content-Type; ist dieser application/xhtml+xml dann sollte der Browser das wie echtes xml parsen, was dann auch in schönen Fehlerseiten im Firefox resultiert

Ich erinnere mich dunkel, dass der IE(6) schon abdreht, wenn die Dateiendung ".xhtml" statt ".html" lautet, auch wenn's gültiges XHTML (oder auch HTML4) ist.

IE kann kein XHTML verarbeiten.

Habe das problem jetzt gelöst, indem ich mir meinen eigenen Webserver programmiert habe. Läußft wunderbar bei 50 aktiven clients mit 30 requests pro sekunde bei 0-2% prozessorauslastung