Thursday, December 13th, 2007

The Future of Comet: Part 1, Comet Today

Category: Comet

Jacob Rus keeps the run of great content on Comet Daily by talking about the the future of Comet: Part 1: Comet Today. Jacob discusses the hacks that we use for Comet, compared to the server-sent events and event-source specs that are finally getting implemented. He then goes through the current trade-offs behind current solutions:

  • “Forever-frame” iframe streaming
  • htmlfile ActiveX object
  • XHR multipart
  • XHR streaming
  • XHR long-polling
  • Script tag long-polling (“CometP”)
  • Flash and other plugins

With this impressive list of transports, we can cover all recent browsers (IE 5+, Safari 1.3+, Firefox 1.0+; Opera 8.5+ as described next time) without unseemly side-effects, using our choice of streaming or long-polling, and can support browsers back much further than that, with a few usability niggles. Unfortunately, however, this requires careful implementation of our server code and browser-side JavaScript, which must coordinate to agree on a transport. This coordination problem, along with browser’s cross-domain security policies, prevent us from using real-time sources in the kinds of mashups built from other web services. The barriers to entry for Comet are much higher than for non-real-time content, and success relies on loopholes in existing browser objects. Wouldn’t it be nice if every browser used the same mechanism, which could stream events across domains securely and efficiently, and web authors could in turn write straight-forward HTML and JavaScript, and send but a single format from the server? Stay tuned for part 2, which plots a course to such a future.

Posted by Dion Almaer at 6:54 am
1 Comment

3.4 rating from 28 votes

1 Comment »

Comments feed TrackBack URI

ItsNat already supports a sort of server-sent events in Java. From server you can fire W3C DOM Events and send them to client (in the client are converted to native events) dispatched in the browser simulating user action, any listener (onclick etc) of a target element is executed as usually.

Furthermore, if there is a server-based listener listening for this event type and associated target element, then a AJAX event is sent to the server and is received by this listener. The cycle server-client-server is closed.

The upcoming version 0.2 will include server events directly dispatched to server DOM with no browser interaction!

– Server based functional web testing
– Bookmarking of AJAX applications (user actions can be simulated to drive the application to the desired state) including Google friendly AJAX applications.
– Add your app. here.

Comment by jmarranz — December 14, 2007

Leave a comment

You must be logged in to post a comment.