Rails core - Mar 2013 - Using rack.hijack with ActionController::Live

Pinging @tenderlove

Some questions on how best to move forward with this:

1.) AC::Live is making use of the stream object on 
ActionDispatch::Response. Should the rack.hijack_io object be used instead 
of this in AC::Live or should ActionDispatch::Response be changed to use 
rack.hijack_io?

2.) What do you think about changing AC::Live to work with adapters? I 
suspect the primary use case for AC::Live will be for websockets, it would 
be nice to set a websocket adapter that "just worked" by hooking into 
AC::Live.

- Brian

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Tue, Mar 26, 2013 at 07:50:53AM -0700, Brian Cardarella
wrote:
> Pinging @tenderlove
> 
> Some questions on how best to move forward with this:
> 
> 1.) AC::Live is making use of the stream object on 
> ActionDispatch::Response. Should the rack.hijack_io object be used instead 
> of this in AC::Live or should ActionDispatch::Response be changed to use 
> rack.hijack_io?
The non-buffering stream object should be implemented in terms of
hijack.  IIRC, AC::Live is the one that provides a `stream` method that
actually does anything.  The default `stream` just returns a buffer.

> 2.) What do you think about changing AC::Live to work with adapters? I 
> suspect the primary use case for AC::Live will be for websockets, it would 
> be nice to set a websocket adapter that "just worked" by hooking
into
> AC::Live.
If we can provide a real IO object, it should just be a matter of mixing
in another module.  I''d suggest we get AC::Live implemented in terms of
hijack before figuring this out.

-- 
Aaron Patterson
http://tenderlovemaking.com/

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hey Aaron,

Sorry I let this go stale but "real world" got in the way this past
month.

Anyway, I''m back on this.

I''ll send a PR for this soonish. I think the first pass will just be to
replace to response.stream object with the rack.hijack_io socket. This will 
change the API somewhat but we can work from there. Perhaps a proxy object 
wrapping the socket?

On Tuesday, March 26, 2013 12:16:34 PM UTC-4, Aaron Patterson
wrote:
>
> On Tue, Mar 26, 2013 at 07:50:53AM -0700, Brian Cardarella wrote: 
> > Pinging @tenderlove 
> > 
> > Some questions on how best to move forward with this: 
> > 
> > 1.) AC::Live is making use of the stream object on 
> > ActionDispatch::Response. Should the rack.hijack_io object be used 
> instead 
> > of this in AC::Live or should ActionDispatch::Response be changed to
use
> > rack.hijack_io? 
>
> The non-buffering stream object should be implemented in terms of 
> hijack.  IIRC, AC::Live is the one that provides a `stream` method that 
> actually does anything.  The default `stream` just returns a buffer. 
>
>
> > 2.) What do you think about changing AC::Live to work with adapters? I
> > suspect the primary use case for AC::Live will be for websockets, it 
> would 
> > be nice to set a websocket adapter that "just worked" by
hooking into
> > AC::Live. 
>
> If we can provide a real IO object, it should just be a matter of mixing 
> in another module.  I''d suggest we get AC::Live implemented in
terms of
> hijack before figuring this out. 
>
> -- 
> Aaron Patterson 
> http://tenderlovemaking.com/ 
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.