add hijack io support to streaming once spec is finalized

[rkh]

see rack/rack#481

[digitalextremist]

Seems like this rests on Stream being more generically evented, and using rack.hijack:

https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L425 needs to be scheduler agnostic, or at least not explicitly demanding EventMachine? Celluloid::IO for example, especially when Reel is the Rack handler, ought to be detected injected, or declared and used. Not everyone uses EventMachine for evented IO, as you know. Celluloid has a much better API and performance also.

Support for rack.hijack is being addressed on celluloid/reel#42. Right now I am using Sinatra on top of Reel. I will need to go in this direction and I'd rather it be a reusable solution that contributes toward this issue. Whatever comments you have here would be great.

Right now I have the browser returning a 101 status, switching protocols, and the socket is exposed through rack.hijack. I just need Sinatra to grasp it and hold it as a genuine websocket, and not just as a long-poll, otherwise the browser just keeps reloading, trying to settle into communicating bidirectionally across its websocket connection.

[digitalextremist]

Seems like this rests on Stream being more generically evented, and using rack.hijack:

https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L425 needs to be scheduler agnostic, or at least not explicitly demanding EventMachine? Celluloid::IO for example, especially when Reel is the Rack handler, ought to be detected injected, or declared and used. Not everyone uses EventMachine for evented IO, as you know. Celluloid has a much better API and performance also.

Support for rack.hijack is being addressed on celluloid/reel#42. Right now I am using Sinatra on top of Reel. I will need to go in this direction and I'd rather it be a reusable solution that contributes toward this issue. Whatever comments you have here would be great.

Right now I have the browser returning a 101 status, switching protocols, and the socket is exposed through rack.hijack. I just need Sinatra to grasp it and hold it as a genuine websocket, and not just as a long-poll, otherwise the browser just keeps reloading, trying to settle into communicating bidirectionally across its websocket connection.

[rkh]

No, moving to the hijack API, Sinatra will not have to deal with concurrency at all anymore. Main issue is that it will stop working with Thin and Rainbows. So what I'd actually like to do is add a shim middleware that will implement the hijacking API for these.

[rkh]

No, moving to the hijack API, Sinatra will not have to deal with concurrency at all anymore. Main issue is that it will stop working with Thin and Rainbows. So what I'd actually like to do is add a shim middleware that will implement the hijacking API for these.

[maccman]

Looking forward to this!

[maccman]

Looking forward to this!

[b-dean]

@rkh, whatever happened to this? Does the shim middleware exist somewhere that we can use it? on rack/rack#481 you mention that this will be in Sinatra 1.4, but that was a long time ago and I still don't see a way to use this with Sinatra's stream helper method (which is where I would expect it to show up).

I actually made sinatra/sinatra#1035 because I was having issues getting streams to work on puma. I'm guessing it's related to this (because puma just keeps closing my stream).

[b-dean]

@rkh, whatever happened to this? Does the shim middleware exist somewhere that we can use it? on rack/rack#481 you mention that this will be in Sinatra 1.4, but that was a long time ago and I still don't see a way to use this with Sinatra's stream helper method (which is where I would expect it to show up).

I actually made sinatra/sinatra#1035 because I was having issues getting streams to work on puma. I'm guessing it's related to this (because puma just keeps closing my stream).