Comet (server push) decorator for TurboGears!

[gasolin]

Hi Guys,

I'd like to inform you that vgod had implement the Comet decorator for
TurboGears (CherryPy+Javascript) while he developed his web-game.
http://blog.vgod.tw/?p=166

Comet (server push) decorator enable you to maintain a long-lived HTTP
connections to reduce the latency with which messages are passed to the
server (think about GMail's GTalk integration or Meebo)

Here's an article that give Comet a good introduction.
http://alex.dojotoolkit.org/?p=545

Since vgod's post is in chinese,
you may want to download the tutorial code (in english) directly
http://blog.vgod.tw/go.php?http://vgod.tw/projects/Comet/CometTutorial.zip

Unzip the file and run 'start-CometTutorial.py' with TurboGears 1.0b1.

--
Fred

[Joost Moesker]

Here's a link to the Google translated verions of the article:
http://tinyurl.com/y7g3wl

[Chris]

If this is true, then it's great news. In fact I recently asked about
Comet support in cherrypy-devel, and they said there's nothing
currently implemented and it might take a year to develop something on
the scale of Divmod's Athena.

However, when I run the tutorial project all it serves up is a page
saying "start". Is that the correct result? How does that illustrate
Comet support?

Regards,
Chris

[Karl Guertin]

On 11/8/06, Chris <chri...@gmail.com> wrote:
> If this is true, then it's great news. In fact I recently asked about
> Comet support in cherrypy-devel, and they said there's nothing
> currently implemented and it might take a year to develop something on
> the scale of Divmod's Athena.

I'm pretty sure they're referring to the fact that cherrypy is a
threading server, so you'll only be able to support as many users as
you have threads open.

> However, when I run the tutorial project all it serves up is a page
> saying "start". Is that the correct result? How does that illustrate
> Comet support?

If you look at the source, there's a "waiting..." and then "start"
after 5 seconds. The "start" is the server push.

I've been thinking about something like this for a while, but I've
been holding off on implementing it until TG was WSGIfied and running
in an environment that can efficiently support many users, such as
twisted.

[Joost Moesker]

This decorator doesn't solve the scaling problems associated with
longlived HTTP connections. It still uses one (sleeping) thread per
connection.

One way to support comet in turbogears is to use a modified version of
the Cherrypy WSGI server. The WSGI app and server use some sort of
signaling system to notify the server when the app is ready to produce
content (e.g, continue iteration).

I have spend some time to modify the cherrypy WSGI server such that it
could multiplex connections. Once I got it running I noticed alot of
new problems. Problems that twisted already solved using deferred
objects. The thing is that you would use comet for event based
use-cases. And (curently) the synchronous WSGI model doesn't really fit
for such use cases.

Python 2.5 support for echanched generators (pep 342) however, might
provides new ways tackle this problem.

http://tinyurl.com/v6pms (link tot he modified CP WSGI server)