On Tue, May 22, 2012 at 3:39 PM, Alex Grönholm <alex.gronh...@nextday.fi>wrote:
> 22.05.2012 10:38, Sylvain Hellegouarch kirjoitti: > > >> In other words: The responsibility for the connection (and socket) is >> passed to the application. >> >> This works well with traditional threaded servers. The application can >> spawn a new worker thread, put the job into a queue or whatever and then >> return from the application callable, allowing the server thread to >> continue handling new connections. >> >> > This is exactly how ws4py was implemented when using CherryPy for the > HTTP server performing the handshake [1]. There's also a WSGI middleware > [2] but it's heavily geared towards gevent and may not be reusable easily > elsewhere I'm afraid. > > It's also a hack that violates the WSGI spec. It's also not usable through > reverse proxying or FCGI/SCGI. > Yeap that's very true and it'll stay a hack until WSGI is updated to support it or explicitely reject protocols such as WebSocket. In the meanwhile, I'm personally fine having projects like ws4py to play with and decide what could work and what couldn't. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
