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) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
