Comet or no comet?

People seem to be quite emotional whether UniversalComet deserves the word comet in the name, so here is some background on the technical details.
The UniversalComet API described in the last two posts uses a very simple/naive technique called polling to achieve the effect of near instant delivery of messages. The reasons for this kind of implementation are very simple and related to the fact that the application is implemented on top of Google App Engine (GAE):

• GAE only allows a single unified response for HTTP requests. This means that techniques involving multi-part responses with multiple script-tags do not work.
• The GAE quota system puts severe penalties on calls to sleep. Thus it is not really possible to implement a system where you would minimize the number of HTTP requests by waiting on the server until a reponse is available (even very short delays within 1 second are not accepted). I'm actually in touch with Google about this topic and there is hope that this limitation might be removed.
• There is also a related issue on the GAE issue tracker.
  

Thus it made sense to use the simple polling implementation. On the other hand, it is true, that Google App Engine is currently not the right platform for implementing scalable comet solution (Although it deals quite well with the current traffic amount). One would have to look for custom hosting or a more liberal services like EC2 instead. However, App Engine is great to deploy just-for-fun proof-of-concept applications without having to worry all the hard stuff behind the scenes.

Anyway, the motivation behind UniversalComet was not really to explore implementation techniques for comet but rather an experiment to provide a very convenient way to give an URL to visitors of a website through which they can be contacted in near realtime by means of simple HTTP requests which I still think is a very interesting idea.