Re: implementing long poll in grails

Thanks, Robert, for sharing all that expertise.

I have several reasons why I'm pursuing this approach.

The most important one is, as you said,

>Don't fight HTTP's nature: work with it.

With this kind of Ajax long polling implementation you don't need any plugins neither client side nor server side or any extra standards. It's just plain HTTP, HTML and a bit of Javascript. That's why it works with all browsers out there, no exceptions. And all server side languages, not just Java.

Firt of all please take care in using the expression long polling. Long polling does not mean that you wait a long time between client side polls. Long polling means that you poll and wait for the server reply, and then re-poll. What you are proposing is just Ajax periodical update with decay. With a decay, you are implementing a mix of both approaches. Why don't you just right away wait until the server has news and replies. There is nothing against it.

I made a long design study and concluded for myself that Ajax long polling (i.e., wait for the reply forever) is actually the better way of implementing Comet style, because traditional comet uses XHRstreaming or hidden IFrame and stuff, all of which don't work properly in all browsers.

Sorry my best reference is only a German website on long polling (i.e., wait for reply, then re-poll) but just have a look at the code example if you care and you'll see how simple it is.
http://wiki.ajax-community.de/tutorial:erste-schritte-mit-comet-longpoll#kompatibilitaet

I'm developing without any plugins because my web app must work with even the simplest clients like PDAs that don't have any rendering plugins whatsoever, just a browser. Besides, all the recent browser updates made a lot of effort speeding up JS rendering. Just look at Apple's recent Safari which is supposed to beat the JS rendering speed of the other browsers by a factor of six. I really want to stick to plain JS and don't adopt another specific rendering plugin which could, in two years, no longer be on the market. My product is supposed to be long lasting.

Here is an English reference which is second best in my list but please first look at the code example in the first reference.
http://www.webreference.com/programming/javascript/rg28/

The only drawbacks I've seen so far is that
a) in older browsers the number of open requests is limited to two. So you need to make sure you close requests client side that are not needed.
b) open requests on the server side normally mean an extra threat per request. But please imagine that a web server must be able to handle thousands of them, so if a few of them add a second threat for a while
it doesn't make a big difference.

Honestly, if I had a choice I would wait until HTML 5.0 web socket standard is available in all browsers http://cometdaily.com/2008/07/04/html5-websocket/
which would provide a standard way of two way communications.

But until then, just plain HTTP.