+1 on "websockets a better fit". The exact fit ;) After all, it can go very nice with erlang messaging concept. http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
On 2 November 2010 21:22, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > On Tue, Nov 2, 2010 at 19:32, Jan Lehnardt <j...@apache.org> wrote: >> Can you qualify "better fit". Not trying to throw stones your way, but >> what exactly makes it better in your view? (Maybe all I need is a link >> to the ticket :) > > I don't think there's much in the ticket. > > It seems to me that HTTP is fundamentally a request-response protocol. > You can do multiple requests over a single connection, but that's not > what the changes feed does. The way HTTP is used for the changes feed > seems to be, "here's this response that never ends, be sure to poll it > once in a while to see if it's grown". On the other hand, the > WebSocket model seems to fundamentally be about sending small(er) > chunks of data between HTTP server and client, which seems to be a > better fit for the continuous changes feed conceptually, and would > probably make accepting those chunks from JS running in a browser and > updating your page state with them much easier, just because now we're > talking about small chunk events instead of a growing response > document. > > Cheers, > > Dirkjan > -- DU
