IE makes it difficult for two reasons: (a) IE’s XMLHttpRequest component doesn’t tell you anything about the response until the connection has closed – even if you try polling it instead of relying on onReadyStateChange, you’ll still get an empty string (Try it); (B) Okay, switch to plan B and inspect IFrame content – we can’t rely on onload, which is only called once at the end, so we *must* poll. But no, polling won’t help either, as the IFrame content remains empty until (you guessed it) the connection is closed. (Try it).

The portable solution is this: Have the server continuously output script tags that call a known function in the parent frame. When you set the child IFrame’s source to point to this service, it will start evaluating the inline scripts as they pop out of the server.

Of course, none of this is really new, at least not to some people. Ajax pioneer Brent Ashley points out:

The ReadyState 3 issue that Michael talks about has been well known (well, apparently not well known) at least since Scott Andrew LePera described the problem in late 2002. It really needs to be fixed.

Hopefully, future versions of IE will expose the ongoing response while the XHR connection is still open. But until then, we at least have a workable technique that works across different browsers.

This area isn’t very well-documented; It would be good to hear what others have done to make streaming portable.

OK, this is so 1999. I tried this back then, only problem being that it not scalable in PHP. So I actually reverted it back to a polling mechanism (I just had the hidden iframe reload rather than pause and wait on the server side). Nice that you could use mostly the same code to do it either way, though. But really, it was great holding the socket open in a test environment, and to show how cool it was (in 1999). But to have thousands (tens of thousands, actually) using it is to have that many PHP processes running simultaneously. Blah! Ick! Yuck! $$$!

Sigh. I get tired of this.
One has to remember that the original MSXML parser (i.e. XMLHTTPRequest) was intended to be used in places other than in script–as in C++ and VB, both of which could read IStream objects and actually *do* something with the incoming responseStream or responseBody while it is being filled, both of which represent a stream of bytes which may or may not be complete.

We as part of the scripting community need to remember that not everything is perfectly accessible from script, nor are certain things originally designed to work that way.

I did some fiddling around with this a while back, trying to do a multi-client chat thing with a broadcast socks server. It worked, but the whole thing is pretty experimental. I tried to explain the technique as well. Enter some junk name and then up your font size. ;)

I think Google is using a somewhat similar approach with Gmail (as Alex Russell covered several months ago,) and while it works, I think it’s a crazy hack. A technical feat mind you, but still – actually being used in a large-production site? – woah! :)

I did something similar, Scott, using a hand-rolled web server that multiplexed connections to avoid running a huge number of CGI processes just to send data out. There was a “control socket” that other local processes could connect to “dispatch” additional data to any one (or all) of the listening clients.

Not everything needs to be done using CGI and stateless HTTP — use HTTP to initiate the connection, (since that’s what the browser talks), but then hand the whole thing off to custom code.

Comment by Andy — June 6, 2006

It’s funny how the popularity of the web browsers as an application development environment brings back old problems as new. I think i solved this in 2000. In any case, if you’re using Javeline TelePort or Javeline FrameWork this solution is in there.

[…] Ajaxian has a great little post (”IFrame + Script Tags = Portable Comet“) about IE and Comet and how they don’t play nice together yet. But, they also mention that there is a (hack hack) workaround. It uses IFrame and script tags. […]

@Tom and @Ajaxian: Yep, they NEED to fix the commenting system… I can’t believe this is still not working properly. That, and the shear volume of worthless posts is getting me pretty close to deleting this feed.

Comment by Ryan Gahl — June 7, 2006

[…] Ajaxian OfficeTheir vision is to be a complete, fully functional MS Office clone on-line. They let you import Excel and Word and other formats into their products. Michael Arrington: You guys have a reputation of […]

Does anyone have any data on server performance with polling vs. comet to push data from a server? On a production system with 100’s of users ould it be better to do an AJAX request every 5 seconds to look for an update from the server or do the iframe hack to keep a connection open? The Comet/iframe method worries me if there are 100’s of open connections to the server that aren’t closing. But at the same time, pounding the server by 100’s of users every 5 seconds doesn’t seem happy either. What are your thoughts on performance between these two methods?

Comment by Jeremy — June 7, 2006

Jeremy,

It depends how the connections are managed. If you are allocating a spare thread for them, then polling will perform better. But if you implement it correctly, with minimal resources allocated, you should be able to keep several thousand sockets open without too much problem.

I haven’t actually done it mind you — but in theory that’s how it should work ;)

At the very least you could all do your normal post, and then make another post pointing out that the commenting system sucks. I think then they might get it. Maybe. Probably not, it’s been broken forever so why would they fix it now?

Oh well, at any rate I can take comfort in knowing where I can find a completely blank page on the internet. Just gotta make a post on Ajaxian.

Comment by Ryan Gahl — June 7, 2006

This is the exact technique that CGI:IRC uses. It has worked pretty well in most browsers (and it has hardly needed changing since I wrote in late 2002!).

One big problem with pushlets (or IFrame and scripts tags) is that the browser (at least IE) reads everything into memory, never releases it and eventually slows down PC to a halt. After all its just one huge page for all it knows.
It may work well for low traffic and/or short-lived sessions, but leave it for a few days or try it on a high volume data stream and you’ll see what I mean.

Comment by Gregory — June 14, 2006

Gregory – true, however a call to a Javascript function to loop through the DOM to remove those script tags that have arrived from the server should sort that.

Comment by Nutz — June 17, 2006

Nutz – I don’t remember if I tried it back when I played with this idea, so I tried it again, and alas, it makes no difference in the memory usage. Whether you remove every script tag as soon as it’s processed or not, the memory keeps growing.

Comment by Gregory — June 19, 2006

I purly love this aproach, but im looking for a demo that uses same connection to send and revice data, is this possible? Anyone seen a example of this?

Im looking for an example:

Explenation:
1.Create a long lived http connection, attach a listener on server side for incoming msg (preferable java or php).

2.Click on a button on the page, that uses the already establish connection and send “hi” to the server, the server responed on the same connection channel with “hello there”.