Hi Dietrch, Dietrich Streifert wrote: > Thank you Helder, > > I was afraid of this answer. Is anyone running a comet like concept > with an qooxdoo application?
There's not much to be afraid of ;). A very simple application of this idea is to open an async request from the client which remains unanswered until the server has something it wants to "push" to the client. After the push data has been received the client immediately opens a new request which will again be pending on the server until the next push need arises. (This is sometimes called "long polling"). The only concern here are the numbers of pending requests, both on the server (if you have large numbers of clients) and of course on the client that has a very limited number of concurrent connections it can maintain. The first step is to make sure all long polling from the client is done through a single connection so your client application does not open multiple long polling requests simulataneously. The next optimization is to time-out the long polling request by the server in regular intervals when no push data is available. This allows the server to reclaim sockets, and the client can use its connection resources for other requests before re-opening the long polling connection. This is sort of "interleaving" the connecion needs on the client. You see, the basic idea is simple. But to elaborate this into a smoothly working communication layer you start to create all kinds of infrastructure and handling protocols (E.g if you think a moment about managing request needs against a limited number of resources (parallel connections in this case), you easily wind up with the idea of a request queue and a corrsponding manager). This is all of the kind what you want to see in a framework. I'd like to see that in qooxdoo too... :) > > The first use of this implementation would be to inform the client > about a server outage. Something like "server is currently > unreachable" popup. The qooxdoo application should get a server > heartbeat which, if it stops, leads to a message. > This is actually *not* a use case for server push, but client pull. The server usually is not able to push a message like "I'm currently unreachable" :). This is the case for client pull where the client makes a "ping" request in regular intervals and the server - provided it is available - answers immediately with a tiny ACK message. This is also easy to implement with async requests on the client (but again, a queue would be nice here). Thomas ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
