<br><br><div class="gmail_quote">On Tue, May 22, 2012 at 3:39 PM, Alex Grönholm <span dir="ltr"><<a href="mailto:alex.gronholm@nextday.fi" target="_blank">alex.gronholm@nextday.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
22.05.2012 10:38, Sylvain Hellegouarch kirjoitti:
<div class="im"><blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In other words: The responsibility for the connection (and
socket) is<br>
passed to the application.<br>
<br>
This works well with traditional threaded servers. The
application can<br>
spawn a new worker thread, put the job into a queue or
whatever and then<br>
return from the application callable, allowing the server
thread to<br>
continue handling new connections. <br>
<br>
</blockquote>
</div>
<div><br>
</div>
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.<br clear="all">
</blockquote></div>
It's also a hack that violates the WSGI spec. It's also not usable
through reverse proxying or FCGI/SCGI.<br></div></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div></div><div>-- <br>- Sylvain<br><a href="http://www.defuze.org">http://www.defuze.org</a><br><a href="http://twitter.com/lawouach">http://twitter.com/lawouach</a><br>
</div>