Meant to post this last night, but am on travel with intermittent connectivity. Jerome's reply makes it a bit ad hoc ...
My love of REST and the Web doesn't quite extend to the use case of a large N of concurrent clients monitoring a single source of near-realtime events. To me, this is the kind of application that cries out for UDP, multicast and other low level techniques for extreme scalability with responsiveness. And a heavy client that can use these techniques. But I've been in the spot of needing something like this to work over unaided HTTP in a browser for whole-product reasons. So here is a pattern I've used in practice, for a law enforcement application; it works okay and customers like it, but the design still feels forced to me -- the whole use case is not a great fit for a pure browser-based application. I couldn't use Comet style here, because it has the side effect of long-term locking up one of the allowed connections from the browser to the originating host, and this was not acceptable to the application requirements. So it uses regular AJAX, with hand coded Javascript bits in the browser as the client (this was before GWT became stable...) So in my app, the UI's model is initially constructed with REST semantics by the client GETting resources interesting to the model. Here, the modeled objects were traffic cameras; in your case I guess these would be equivalent to phone stations or call queues. This model-building operation is comparatively expensive, but only happens when the UI initializes. This is all normal REST/Restlet/Resource stuff. As interesting events happen on the server (in my case, cars go through the cameras), events are sunk into an event log. These are packaged in extremely terse form, just enough for a UI client to update its model (show appropriate iconography and text for each camera's finding). There is also an event which says "reload models please," e.g. if a camera was added or removed from the network. When the UI client initializes, it is given a pointer location P in the event log that corresponds to the timestamp at which the full model information was downloaded. Subsequently, the client polls the server's event queue resources (for the specific objects that are "onscreen") using AJAX, effectively asking "get events since P" My implementation uses conditional GETs (If-modified-since) and the Not Modified response for extra terseness when there is no news in the queue. So there's not even an entity body transacted unless something happens, and then only enough data to represent the changes that must be shown in the UI. Given that HTTP/1.1 is typically used and the total size of an exchange is thrifty, many, many concurrently polling clients can be supported, especially with an NIO-based server. In my app, the poll interval is self-throttling and not deterministic; a client begins a new poll after the last poll completes, plus any configured delay. As John said, instant updates may not be needed; a second or three may be an acceptable delay between UI updates. This design ensures that eventually every client will see every event, but there is no realtime or near-realtime guarantee. The faster/better the client computer, the closer to realtime its performance. Anyway, not sure any of that is relevant to what you want to do ... if you forge ahead on the Comet path please let us know how things come out. - R
