Friday, January 18th, 2008

Native Comet Support for Browsers

Category: Comet

As JavaScript developers, we are used to years of hacks, as we try to push forward without browsers updating and helping us out. We are so stuck in this pragmatic thinking that we sometimes forget to pick our heads up.

Kris Zyp has taken some time to think about Comet, and instead of thinking about the next good hack, he takes that step back and dreams:

What if I had commit privileges on all the major browsers, the competence to add functionality in all the code bases, and wanted to add native Comet support in a form that was easily accessible to developers?

He ends up with a proposal that adds to good ole XHR:

With only a few simple XMLHttpRequest API additions, Comet communication could be realized with a native implementation that supports fast and efficient standards-based two-way asynchronous communication, with true server-delivered HTTP streaming and simple subscription requests, with the added benefit of client-delivered streaming and cached resource until updated capability. Developers could create Comet applications with a standard API without hacks. Communication could be standards-based, allowing current servers to easily implement the necessary features to handle communication.

It would look something like this:

javascript

  1. var cometXHR = new XMLHttpRequest;
  2. cometXHR.open('POST','comet',true);
  3.  
  4. var xhr1 = new XMLHttpRequest;
  5. cometXHR.addHttpChunk(xhr1);
  6. xhr1.onreadystatechange=function(){...}
  7. xhr.open('GET','/ticker1',true);
  8. xhr.send();
  9.  
  10. var xhr2 = new XMLHttpRequest;
  11. cometXHR.addHttpChunk(xhr2);
  12. xhr2.onreadystatechange=function(){...}
  13. xhr.open('GET','/ticker2',true);
  14. xhr.send();

Kris gets into many of the details, and makes me with that someone would implement this as a Google Gear, so it could get pushed into the fabric of the Web by being on all browsers.

Posted by Dion Almaer at 9:26 am
7 Comments

+++--
3.7 rating from 29 votes

7 Comments »

Comments feed TrackBack URI

W3’s XMLHttpRequest standardisation process is still in working draft. Best way to get it added would be to send a proposal to the public-webapi@w3.org mailing list, then to defend it.

Comment by Robin — January 18, 2008

Why Comet? Why not JavaScript Sockets? You know, sockets, like what “real” applications use… True bidirectional communications.

I’m using Sockets all the time for my web applications using Flash. It works great.

Comment by pkenoyer — January 18, 2008

@ pkenoyer: I gotta agree with your idea of implementing Javascript Sockets. That would make things so much more flexible than just extending XHR. Libraries could be built on top of low level sockets to abstract away all of the details, and we could experiment with several different Comet approaches until a clear winner emerges. Its only when a common pattern emerges that we should begin thinking about formalizing the approach.

Comment by dkubb — January 18, 2008

Agreed with pkenoyer, if anythings gonna get implemented, native javascript sockets would be better. But it might be more likely for something like this to be implemented until sockets get standardized because it will be easier to handle fallback for older clients.

Comment by Andy Kant — January 18, 2008

Sockets is the way to go. In doing the research for my upcoming Ajax book it was clear that trying to jam a two direction persistent connections into a connectionless protocol – yes that is what you are doing – is simply a hack even in the best cases. Interestingly it is clear that the implementation of the first native Comet like stuff as Opera does is really just the same stuff we have lurking under an API. Though we should all note that as soon as we do get what we want (sockets) the firewall impact will be large both on client and server-side. It seems port80 + HTTP is allowed so we just drive everything through it for better or worse.

Comment by Thomas Powell — January 18, 2008

Sockets is good for certain applications with controlled clients, but with firewalls and proxy servers, it is not really a practical solution for general Comet use, as Thomas pointed out. Client sockets often get through proxy firewalls, and server sockets get you no where. Direct TCP/IP/Sockets doesn’t really provide that much HTTP, if you have full bi-directional streaming in HTTP (which is supported by the protocol). Sockets don’t get you much, it is bi-directional streaming that is needed and HTTP is right place for it.
Thomas, I am not sure what you mean by Comet being “connectionless”. Most Comet apps have a very strong concept of a connection (within which they send subscriptions and receive relevant events).

Comment by kriszyp — January 18, 2008

I also agree that sockets are much better than Comet. It’ll have to due, I guess, but I’d much rather have true bidirectional communication than a work-around. The problem is there are too many issues in implementing it (firewalls, browser support *coughIEcough*, etc).

Comment by musicfreak — March 11, 2008

Leave a comment

You must be logged in to post a comment.