yeah, that's why the "Web 2.0" makes me laugh.. didn't we have
bidirectional protocols 30 years ago?
anyway, i'd argue that HTTP *can* be used as a bidirectional protocol.
if the client sends a chunked request body with no content length, and
the server sends a chunked response body with no content length, you
have achieved bidirectionality. HTTP effectively becomes a tunnel for a
bidirectional protocol based on XML or whatever you care to use.
the only major hitch is whether you can get software like firefox (or
dear gods, IE) to play along. we can assume we can control the server
side and fix apache or just use POE etc.
-tavin
Philip Gwyn wrote:
Breifly, cometd is an AJAX implement.
AJAX works by using HTTP requests "in the background," that is not a page load.
HTTP is a client-driven/initiated request/response protocol. That is, clien
opens the connection, sends a request, server responds. Repeat
if using keep-alive.
Which is to say, it is impossible to convert an HTTP connection into a general
by-directional protocol.
Cometd works around this by having the server queuing up requests, and the
client polling for them every X seconds.
There are also, I believe, more advanced/complex techniques. But I don't
remember the details.
Regarding apache, back in the day nph-cgi was used for server-push stuff (like
animations, pre-animated gif/flash days)
-Philip
On 23-Feb-2007 Tavin Cole wrote:
have you figured out a way to make the connection truly interactive, in
the sense that the client can send a message at any time while receiving
the multipart server push, without opening a second connection?
i ran into lots of problems trying that, where i couldn't get firefox to
send a streaming request body, and i couldn't get apache to give the
request stream to the CGI/PHP/ModPerl instead of buffering it until the
whole content-length is read.
no doubt you can solve the problem server-side with POE, but what about
the client-side?
-tavin
