Re^2: Perl modules for Comet ?

Yes, I've seen that (via multipart/x-mixed-replace)...but I'm under the (possibly mistaken) impression that Comet doesn't use multipart bodies ?

The relevant term is "flush". on FF (and pretty much everywhere but IE), XmlHttpRequest.responseText will contain whatever the server has "flushed" to the client. But I can't find a precise definition of "flush": is it just the TCP I/O flush, or is it the delimiting of one part of a multipart response (per multipart/x-mixed-replace, which IE also doesn't support) ?

I guess maybe its time to write some code and find out...

Perl Contrarian & SQL fanboy

Comment on Re^2: Perl modules for Comet ?

Replies are listed 'Best First'.
Re^3: Perl modules for Comet ? by Joost (Canon) on Feb 10, 2007 at 22:10 UTC
As far as I've been able to find out since you posted your OP, there is no real standard for doing all this. I guess you should be able to just flush the output buffer whenever you have a chunk of data ready and let the client-side code figure out how to break up the stream in ready chunks. I do know that relying on multi-part bodies alone (without client-side code) does not work as well as you'd hope, and I suspect using multi-part bodies will be slightly more work to interpret by your ajax code (if they work at all) than a custom (simpler) format. update: if you want to do this seriously (i.e. multiple events, many clients) with perl, you probably need a special light-weight server for the event streams, if only because having a few hundred apache processes will eat your memory. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^4: Perl modules for Comet ? by renodino (Curate) on Feb 11, 2007 at 00:07 UTC
...there is no real standard for doing all this. I'm discovering the same. Similar to its namesake cleanser, its very green, and a bit abrasive ;^) ...you probably need a special light-weight server for the event streams... Yes, ergo HTTP::Daemon::Threaded (tho some may contend its heavier than Apache). However, my target is more like 20-100 concurrent users, rather than thousands. Think "application appliance", not Google scale. Alas, HTTP::Daemon::Threaded currently relies heavily on HTTP::Request/Response, and the latter doesn't adapt well to the "Service Stream" concept. So I'm thinking a subclass of HTTP::Response that adds a "flush" capability may be useful. Perl Contrarian & SQL fanboy	[reply]
Re^5: Perl modules for Comet ? by Joost (Canon) on Feb 11, 2007 at 01:54 UTC
Depending on what you're going to do, a single process & single threaded select() based server might perform better than a threads based one. Especially if you need to share a lot of data over different requests. You might want to examine POE::Component::Server::HTTP. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]