Toward server-sent data w/o iframes
Or at least I thought I was.
At OSCON, I fortuitously meet Johnny Stenback, who informed me that you could indeed get multiple replies from a single request under Mozilla after I'd stated otherwise in a session. Today I started to dig a bit based on his direction and the results are interesting.
But they're not really interesting if you don't have the back story. Previously, I had thought that the only way to keep a connection open and do multiple things with it in a cross browser way was to rely on an incremental rendering hack (which is how the mod_pubsub client works). In this scenario, the client opens up an iframe and points it at a special page that doesn't close the connection. When the server has data, it synthesizes a <script> block which gets sent to the client (sometimes with some padding), which then evaluates it thanks to a "partial rendering" behavior that seems to be part of every browser since time began. The script loaded this way then calls back up to the parent page (on a special function) which then disseminates the event data to everything that had previously registered it's interest. This works pretty well, but falls into the well populated "giant, gratuitous hack" category of useful techniques for doing things in browsers.
Something better would be much appreciated. For a long time, DHTML hackers have eyed Microsoft's XMLHTTP docs with some envy as there is a stream type and an interactive mode which aren't made available to scripting, and there hasn't even been that much promised under Mozilla et. al. So back to iframe hacks we fell. But things are looking up.
It seems that it's now possible to send chunked data to the client in Mozilla on a long-lived connection, and it might very well be possible to do the same thing for IE.
Unfortunantly, unlike the iframe hack, it looks like the format on the wire will be different between the browsers (and things like Safari might still require iframes, which is yet another code branch). Whether or not any of this is a better trade-off than doing something like LivePage or the current mod_pubsub implementation is still up for debate, and only trial-and-error will really tell.
Of course, the biggest hurdle is still the scalability of servers for long-lived "zombie" connections, which things like Java servlet containers completely melt under, but Twisted Python (which mod_pubsub is now based on) indicate the way forward. I think it won't be too long before real-time monitoring and chat features turn into commonplace occurrences in the Web2.0 experience.
It'll just take another set of sexy apps to point the way forward. And a lot of elbow grease.