Hallo Marko,
da im Web grundsätzlich eine Kommunikation immer vom Client angestossen wird, geht es wohl kaum ohne Polling. Der Server kann von sich aus keine Nachricht an den Client schicken (höchstens mit einem Java Applet oder so etwas ähnlichem).
Du könntest aber den Aufwand minimieren, der Client könnte z.B. jede halbe Sekunden einen Status abfragen, der nur 1 oder 0 zurückgibt, je nachdem ob sich etwas geändert hat. Nur bei Änderungen wird dann die kompletten Werte übertragen. Lohnt sich aber auch nur wenn Du damit wesentlich etwas sparst.
Das erinnert mich irgendwie an das "Observer" design pattern von Java: Das Subject ("Observable") gibt allen registrierten Komponenten (den "Observern") ein Signal, wenn sich bei ihm etwas geändert hat. Entweder, er liefert die veränderten Daten gleich an die lauschenden Klassen mit (push-Methode), oder, die einzelnen Komponenten holen sich die benötigten Dinge selbst, wenn das Subject ihnen mitteilt, dass sich etwas geändert hat (pull-Methode).
In deinem Fall kann das Subject seinen Observern allerdings kein Signal senden (bzw. nur über ziemlich blöde Umwege).
Darum finde ich die Idee mit dem "Bit", dass von den Observern erfragt wird, ziemlich gut. Wenn man das noch perfektioniert, sendet man eine Folge von Bits, bei denen jedes für eine Änderung einer gewissen Sache steht. Der Client holt sich daraufhin nur die Informationen neu, die sich geändert haben. Der Server setzt die Bits für geholte Informationen wieder auf 0, wenn der Client sie abgefragt hat. Wenn man mehrere Clients hat, muss man das Ganze natürlich entsprechend erweitern.
Der Overhead ist allerdings _immer_ ziemlich dramatisch, weshalb eine push-Methode (Client agiert also auch als Server) sogar die beste Alternative wäre.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
Linux is like a wigwam - no windows, no gates and an Apache inside!
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
http://emmanuel.dammerer.at/selfcode.html