Prinzipiell: NEIN
In HTTP ist kein Mechanismus vorgesehen, der Events vom Server generiert.
Es gibt ein paar mehr oder weniger elegante Lösungen, die das Umgehen können:
1. Iteratives Polling:
Der Client sendet in regelmäßigen Abständen "Pings" an den Server, um zu kontrollieren, ob ein Interrupt vorliegt. Ist das Ergebnis positiv ruft der Client den Status von Server ab. Wird meistens mit AJAX realisiert, damit die geladene Seite stabil bleibt. Leider ist die Methode nicht sehr effektiv. Es gibt eine Unschäfe bezüglich Trafficverbrauch und Reaktionszteit: Je besser die Reaktionszeit, desto mehr Serverlast wird erzeugt (durch redundate Requests).
2. Nichtgeschlossene Session:
Mit HTTP 1.1 ist es möglich über eine Verbindung mehrere Dateien runterzuladen (um den Verbindungsaufbau zu sparen). Es ist möglich nach dem Herunterladen der Seite die Verbindung im Wartezustand zu halten. Wenn nun ein Javascript-Prozess über die Verbindung wacht, und beim Eintreffen neuer Daten einen Server-Event abarbeitet, hast du auch dein Ziel erreicht. Nachteil: Der User hat die ganze Zeit einen Ladebalken, der symbolisiert, dass die Seite noch nicht vollständig geladen wurde. Außerdem muss es der Client können. Könnte auch sein, dass der Server irgendwann einen Timeout bringt und die Session schließt.
3. Benutzen von aktiven Inhalten:
Wenn du auf der Seite eine aktive Komponente (z.B: ein Java-Applet) laufen lässt, die Socks-Verbindungen erstellen kann, und deinen Server so konfigurierst, dass ein weiterer Event-Server auf einen weiteren Post lauscht, kannst du auf diese Weise Events übertragen, und diese mit Javascript von der aktiven Komponente abfragen.
Fazit: Es ist sehr kompliziert und erfordert immer ein großes Maß an Konfigurationsarbeit. Außerdem funktioniert es nur, wenn aktives Scripting möglich ist.
Ich habe auch noch keine dieser Methoden im Feld proviert und kann deswegen nichts zur Umsetzbarkeit sagen.
Ich würde es lassen, und statt dessen für sowas gleich ein Applet hernehmen.
mfg, metax.