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.
Server im Http-Server ;)
JaY0Gi hat geschrieben: Gibt es dabei irgendwelche Limitierungen*, z.B. kann diese Verbindung "unendlich lange" aufrecht erhalten werden?
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.
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.
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.
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.Jan.O hat geschrieben:JaY0Gi hat geschrieben: Gibt es dabei irgendwelche Limitierungen*, z.B. kann diese Verbindung "unendlich lange" aufrecht erhalten werden?
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.
-
mitsuhiko
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
[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.
TUFKAB – the user formerly known as blackbird
Danke für den tipp! habe meine tests auch immer mit normalem html-code gemacht.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.
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 resultiertY0Gi hat geschrieben:Oh, gut zu wissen. Wonach richtet sich das denn? Dem Content-Type? Dem DOCTYPE? Dem Namespace?
