Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-08 Thread Boaz Segev
Hi Sam, I just wanted to point out that the specification was meant to be optional and this is why it includes the `env['upgrade.websocket?']` flag to indicate support. I don't think every server has to support Websockets - different server architectures favor different tasks and performance

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-08 Thread Eric Wong
Sam Saffron wrote: > For the record Eric, > > We use unicorn at Discourse to serve concurrent long polls across 100s > of hosted forums using hijack with zero issues using > https://github.com/SamSaffron/message_bus Thanks. That's exactly the usage I had in mind when I learned about rack.hijack

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-08 Thread Sam Saffron
For the record Eric, We use unicorn at Discourse to serve concurrent long polls across 100s of hosted forums using hijack with zero issues using https://github.com/SamSaffron/message_bus I am not particularly enthused WebSockets and have blogged about my reservations, in an HTTP/2 world I am less

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-06 Thread Boaz Segev
>> Michael said > Unicorn is a forking webserver, not an event-driven or threaded > webserver. Whether Unicorn ever supports the proposed standard or > not, I wouldn't recommend it be used for typical applications that use > WebSockets, as they usually involve persistent connections. Unicorn > wo

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-05 Thread Eric Wong
Boaz Segev wrote: > Running two (or more) event loops, each with it's own > resources, is wasteful and promotes needless context switches. > > There is no reason to hijack a socket when the server can > easily provide callbacks for IO related events using it's > existing established event loop.

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-05 Thread Michael Fischer
On Fri, Aug 5, 2016 at 8:09 PM, Boaz Segev wrote: > > Your Rack app could take the socket and inject it into an > > event loop running in a separate thread. That event loop > > could be 100% C code running without GVL for all unicorn > > cares. > > > Running two (or more) event loops, each with i

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-05 Thread Boaz Segev
Eric, thank you for your review and thoughts on the matter. You raised a few questions, please allow me to both answer and clarify the intention behind the proposed extension. >> I represent an effort to extend Rack so that it allows server-side >> websocket upgrade implementation support and pu

Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-05 Thread Eric Wong
Bo wrote: > Please join the Rack Specification discussion for `env['upgrade.websocket']` Fwiw, I have not existed outside of plain-text email for years; so I'll respond inline here and you can link others to this thread on: https://bogomips.org/unicorn-public/58d32d89-4523-4

Please join the Rack Specification discussion for `env['upgrade.websocket']`

2016-08-05 Thread Bo
Please join the Rack Specification discussion for `env['upgrade.websocket']` I represent an effort to extend Rack so that it allows server-side websocket upgrade implementation support and pure Rack websocket applications. This new Rack feature proposal is gaining support, with over