SLGOGP Draft 1/Discuss 2-4 Event Queues

• Event queues make sense for the reasons given, but the implementation via long poll seems bizarre and unhelpful. What seems to be happening here is that everything is being seen through the eyes of HTTP, even when that leads to a very bad design. Here are some reasons why it is bad:

• It consumes extra resources on client and server alike, because the communication path needs to be re-established repeatedly both at network and application levels.
• It increases average latency in event handling dramatically, since long poll setup takes a lot of time compared to actual event communication, and poll intervals become subject to the vagaries of client timing.
• It requires contorted client design, with poll points being placed at selected places in the code. (This is the wrong design approach in almost all circumstances).
• It adds nothing useful to using a simple TCP stream for communicating events between server and client. The rationale given for event queues requires clients to establish the connection to the server, but there is no need to ever close this connection as long as that event queue is being monitored. Items sent to the event queue can just continue appearing at the client end through this pipe. Simple TCP is enough.
• It assumes a rather antiquated polling client structure, instead of a modern event-based one which reacts to everything through callbacks. While the long poll may persist the TCP stream for some significant time, it is highly inappropriate if the server side EVER terminates the stream except on event queue shutdown. In general, a modern client wants to set up the event stream once, and thereafter just react to incoming data on that socket, without polling. It is efficient, elegant, and simple.

Summary: Because good event handling is so central to a client's effectiveness, this is a crucial area to get right. Seeing everything through HTTP glasses is not always helpful, and in general polling is a very poor technique for event propagation. HTTP can be used to create the connection, but the opened TCP stream must never terminate except on event queue shutdown. Morgaine Dinova 22:58, 11 March 2008 (PDT)

I don't know how they might do things in the future, but the current EventQueueGet is meant to provide continuity for the existing code-base and I suspect this is the rationale for the new and improved event queue as well. Whether or not this should be the model used for all eternity is a different debate, IMHO. Saijanai 01:58, 13 March 2008 (PDT)

• Some URLs about COMET (which long-polling is part of)

• http://cometdaily.com/2007/12/18/latency-long-polling-vs-forever-frame/ (Latency discussion)
• http://cometdaily.com/2007/11/15/the-long-polling-technique/ (what is long-polling?)
• http://cometdaily.com/2007/12/11/the-future-of-comet-part-1-comet-today/ (an overview over various COMET techniques)

• I think there should be more details on the long-polling technique, e.g.

• State that the request stays open until some event occurs, after that it's reopened
• clients SHOULD implement Keep-Alive so it also can stay open then TaoTakashi 09:31, 13 March 2008 (PDT)