Comments for Toward server-sent data w/o iframes
I would, however, like to see a small XMLSocket package from a Flash person that comes bundled w/ an exposed JS API.
I have to test, but mmm.
It's not that I'm so fond of Java but I know a lot of people who are.
I noted with some interest the continuation support announced in the new Jetty. Perhaps it will provide an answer for Java folks someday (or they could just use Rhino w/ continuations and avoid the throw/catch hackery), but things like Twisted Python and mod_pubsub are here today. No waiting, and no condescending programming language to deal with. Give them a look.
I'm curious about this mod_pubsub thing (have been for a while now) but if I go to the URL you gave (http://mod-pubsub.org/) I get: "You don't have permission to access / on this server."
-- or they could just use Rhino w/ -- continuations and avoid the -- throw/catch hackery
So the typical deployment architecture is based on two distinct clusters: the Pull cluster (a common web server cluster) and the Push cluster (a Lightstreamer server cluster). The browser first connects to the Pull cluster to download al the static resources of the page (html, js, css, images, etc.). Then it connects to the Push cluster to open the push/streaming connection and to subscribe to any item. The real-time updates are sent over the push/streaming connection. In this way the load caused by the real-time traffic is entirely absorbed by the Push cluster (that is specialized for this task), without affecting the traditional architecture of the Pull cluster.
To know more and see some online demos just go to www.lightstreamer.com
I was wondering if somebody actually tried MSXML2.DOMDocument to implement Multi Part XHR. Because I did and failed miserably. Maybe I get something totally wrong but it seems that the ondataavailable is pretty worthless for that matter. MSXML2.DOMDocument calls the handler only every x elments where x is .. well some number (> 200 elems) Even if MSXML2.DOMDocument loads assync it doesn't seem to start parsing the document before the stream is closed (which alone makes it completely worthless) I don't think that anybody ever really considered using it - but since the idea is floating around and is referred to from a lot of blogs ...
By the way: there's almost zero information about this apart from the msdn page mentioned in the article.
It's a Good For Now solution, until browsers are similarly capable on their own.