On 7/14/06, Roberto Saccon <rsaccon@...> wrote:
> Maybe anybody has already spent thoughts on extending yaws for such a thing ?
I scanned their documents quickly and it seems like COMET is about
having the client continously wait for a message from the server, and
the server hold its reply until it has something to say (or perhaps
some timeout occurs).
Yaws can handle many concurrent connections fine, so this is not
really any problem or something that requires new features.
It is the most compatible way to stream. Well, if one doesn't count
using an iframe that the server stream lots of tiny SCRIPT elements to
as the server wants to send a message to the browser. After a few
hundred kilobyte sent, one might want to close the iframe stream and
have client js code reload the iframe to stay online. Yaws supports
Other less compatible ways include using mozilla's multipart messages.
Did you know that one can serve mozilla browsers the MIME type
multipart/x-replace-mixed and then serve images, and if one refers to
that url in an image tag then mozilla will show the latest image
received? Some webcams use this method for streaming video. Anyway,
the mozilla xmlhttprequest can handle these multipart streams. Each
time a full message has been received your event handler will be
called and you can process the received data. (parse json, eval js
code, parse as xml... whatever floats your boat.)
Other ways one can push messages is to use Java applets that set up a
'loading' icon will not be rolling in the browser, the disadvantage:
Not everyone has a jdk installed. This only involve yaws if one want
to communicate back on port 80 (to avoid firewall hassle), but yaws
streaming solves it fine enough.
Be wary that yaws streaming times out after 30 seconds, so one might
want to send a "NOP" message every N<30 second, just to have yaws keep
the connection open.
Then there is flash, it supports something similar, communicating with
one creates such a swf file or if one can be found somewhere?