Comet Gazing: Frustrations

by Comet DailyApril 28th, 2008

Comet Gazing is a semi-regular feature on Comet Daily. We pose a question to our Contributors and post the answers.

This time, we’ve asked our contributors the question: “What do you find most frustrating about Comet development, and how do you workaround or deal with the issue?”

Michael Carter
Orbited

I’ve been annoyed at how hard it is to test out the browsers, and as a result put together a system where you can put raw data to send over the wire in a textarea, and then it comes back down to an xhr / iframe / xml connection (ie) in the same browser page. Adding in firebug lite produced a console to send bits of data and see exactly how the browser reacted, without ever restarting the server or even leaving that page in the browser.

Kris Zyp
Persevere

I have been working on a new Comet transport that will utilize XHR streaming when available. Interactive mode in IE’s XHR implementation doesn’t work, so you can’t do streaming with that (which is terribly frustrating in itself). However, IE8 has introduced a new request API, XDomainRequest, intended for doing cross-site requests. Oddly, this new constructor does support streaming, and it even works. Therefore, I have been leveraging the new XDomainRequest API for this transport. With the combination of real streaming and a 6 connection limit, IE8 looks like it will be much more hospitable to Comet, however the new API has brought it’s own set of challenges.

First, you must provide an absolute URL, no relative URLs are allowed. Second, you can not use an https:// secure URL, only a standard http:// URL. You must fallback to regular XMLHttpRequest for secure servers. Next, when there is an error, the onerror handler is called, with no information whatsoever. The response provides no status codes and no headers even on successful response. On an error, all that you know is that an error occurred, no error codes, no help, nothing. All you can do is go back to the documentation and try to make sure you got every step right. In my case, the documentation was of no help. It turns out that XDomainRequest fails on status codes that are not 200, even the successful status codes (20x). I was planning on using different status codes to indicate the status of the response. Only a 200 status code will work.

Why can’t the IE team just fix interactive mode in the standard XMLHttpRequest API? Read about more of my frustrations with XDomainRequest.

Greg Wilkins
Jetty

The biggest frustration I find is that the browser considers all frames talking to the same server to be in collusion when it comes to resources (i.e. 2 connection limit), but then imposes security barriers between them, so they really cannot collude and share those 2 connections.

The solution to the 2 connection limit issue is not a 4, 6, or 8 connection limit. The solution is to allow frames that are considered to be within the same resource pool to communicate and to share those resources.

Then there are a bunch of other minor frustrations, including:

  • Unreliable onUnload handling. It just makes the work arounds for the 2 connection limit harder as reloads often appear as a second frame connecting.
  • JSON. It’s really expressive and easy to use client side. But server side in Java, it either needs complex object mapping or cumbersome Maps of Maps. Actually this is just a shortcoming of Java that it is verbose and expensive to assemble arbitrary ad-hoc assemblies of related data.

Dylan Schiemann
Cometd

A couple of years ago, the frustrations with the forever-frame technique were rather annoying: incompatibility or crashing with Firebug in early releases, tracking down flushing techniques in Internet Explorer and Safari to enable incremental rendering, finding out that versions of Safari would cache the contents of an iframe even on page reload.

In addition to the regular issues (testing, 2-connection limit, cross-domain support, etc.), I think overall the main frustration is that the bugs and limitations that Comet developers run into tend to be issues not commonly noticed during testing as the number of developers working with Comet is still relatively small when compared with Ajax developers. We’re finding new limitations in browsers on a regular basis, though things are starting to improve. As far as how we workaround this? Testing, testing, testing, discussions with other people interested in Comet, and chatting with a small set of developers working on the major web browsers.

Martin Tyler
Caplin

Most Comet solutions rely on a callback method into the users JavaScript code. It is quite common in software in general as well as in Comet for the library calling the callback to wrap it in a try/catch exception block to try and prevent the user code from breaking things. The problem with this is that it prevents the user from debugging their callback code with standard browser tools like the Microsoft debuggers which can give you full call stacks and information.

A solution to this is for the library to provide a debug mode where it does not wrap the callback. JavaScript provides an easy way to do since you can create two versions of the callback wrapper and easily set which one you use when the library loads up, rather than checking what mode you are in each time a callback occurs.

Another frustrating area, not quite on the development side, is getting people to understand Comet and how a Comet solution differs from more traditional web architectures. This can be a barrier to deployment, especially at large organisations that have policies for deployment that are based on the more traditional web architectures. Web sites like Comet Daily can only help with this problem by spreading knowledge.

Comments are closed.


Copyright 2015 Comet Daily, LLC. All Rights Reserved