New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Fix Stream API #1114

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@HoneyryderChuck

HoneyryderChuck commented May 11, 2016

As discussed in #1035

Plan is to create a better abstraction of Streaming Responses. Most web servers get away with chunked responses, but fail (except EventMachine) to keep the stream open. Most web servers don't have an event loop or abstraction to pass tasks to its workers (when they have them), and only rely on the rack hijack API to "delegate" this task to another component.

This means (IMO) that the Stream class must accomodate the common use case, that means, it has to be able to:

  • keep the IO
  • write the relevant headers (here is an example of a class which does it)
  • schedule tasks to be executed by the event loop and by threaded workers (defer/schedule)
  • handle the case when the socket is closed (according to Rack spec, an open stream object can't respond to close)

Still in progress

out << "It's gonna be legen -\n"
#stream do |out|
Rack::StreamingResponse.new do |out|
out.hijack!(env)

This comment has been minimized.

@HoneyryderChuck

HoneyryderChuck Jun 12, 2016

@zzak do you have some insight about accessing the request env from within the response, so that I don't have to explicitly hijack within the response block? I really don't like that, by the the time "out" is exposed in the block, the socket isn't hijacked yet. My rack-fu is not that strong.

@HoneyryderChuck

HoneyryderChuck Jun 12, 2016

@zzak do you have some insight about accessing the request env from within the response, so that I don't have to explicitly hijack within the response block? I really don't like that, by the the time "out" is exposed in the block, the socket isn't hijacked yet. My rack-fu is not that strong.

This comment has been minimized.

@zzak

zzak Jun 24, 2016

Member

@TiagoCardoso1983 Hmm, good question, I think we shouldn't have to do this but I can't look into it now. Once I clear up some of the backlog I will take a look at new features.

@zzak

zzak Jun 24, 2016

Member

@TiagoCardoso1983 Hmm, good question, I think we shouldn't have to do this but I can't look into it now. Once I clear up some of the backlog I will take a look at new features.

This comment has been minimized.

@HoneyryderChuck

HoneyryderChuck Jun 24, 2016

@zzak no worries, but just as a sidenote, I really think that this has to be addressed first on the rack level.

@HoneyryderChuck

HoneyryderChuck Jun 24, 2016

@zzak no worries, but just as a sidenote, I really think that this has to be addressed first on the rack level.

@namusyaka namusyaka added this to the v2.1.0 milestone Feb 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment