Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows!

[Eric Wong <normalperson@yhbt.net>]

James Tucker <jftucker@gmail.com> wrote:
> On 15 Dec 2009, at 21:32, Eric Wong wrote:
> >> On 15 Dec 2009, at 04:37, Eric Wong wrote:
> >>> James Tucker <jftucker@gmail.com> wrote:
> >>>> On 14 Dec 2009, at 18:42, Eric Wong wrote:
> >>>>> James Tucker <jftucker@gmail.com> wrote:
> >>>>>> I really want to work out an abstraction away from IO instances, #read
> >>>>>> and #write for this stuff. It's highly coupled, getting in the way of
> >>>>>> tests, and heavy lifting environments. I have big plans for Rack 2.0
> >>>>>> to remove all IO that has not been properly abstracted and decoupled
> >>>>>> from implementation details, but that's a long way off, mostly due to
> >>>>>> lack of time and incentive. In the meantime, I can implore you all to
> >>>>>> take steps in the right direction :-)
> >>>>> 
> >>>>> Huh?  I don't see what the problem with IO instances/semantics is,
> >>>>> especially with the availability of StringIO for testing.  "rack.input"
> >>>>> is clearly specified and works fine as-is IMHO, though the rewindability
> >>>>> requirement does add some unnecessary overhead.
> >>>> 
> >>>> I disagree with "works fine". It does not work fine with Thin, in
> >>>> fact, on the contrary, it forces some real ugliness into the system. I
> >>>> also think that StringIO is a really unfortunate thing to have to
> >>>> resort to, as it has so many short comings.
> >>> 
> >>> Mind elaborating?  I do not see what's ugly about it[1].
> > 
> >> Sure. It forces authors to several (bad) APIs options for handling
> >> complex IO scenarios.
> >> 
> >> 1. Buffer the entire request and then republish to the application
> >> 2. Pass forward the raw IO
> > 
> > 3. stream input with a rewindable backing store like TeeInput:
> >   http://unicorn.bogomips.org/Unicorn/TeeInput.html
> >   This is already supported by several (but not all) Rainbows!
> >   concurrency models: http://rainbows.rubyforge.org/Summary.html
> > 
> > I'll need to use Fibers to get this working with Rev and EventMachine,
> > (the FiberSpawn/FiberPool models are select-based), but exposing an
> > outwardly synchronous model is far easier for application developers to
> > grok.
> 
> That's API dependent. And exactly my point, you're forcing them to use
> stack based concurrency models. Doing this means one can never escape
> the weight of stack storage, and moreover, stack wrangling will never
> be as fast as object level state containers. This is not a fact that
> can be escaped.

Everything is API dependent.  TeeInput just conforms to what
Rack::Lint::InputWrapper allows.

Of course stack-based concurrency models will always be slower on the
machine than state machine + event-based models.

Ruby will also always be slower than a lot of other
less-pleasant-to-write languages out there.  It's a tradeoff we make as
Rubyists.  I believe most developers find things like
fibers/actors/threads easier to work with/maintain than
events+callbacks, so Sunshowers got support for linear programming
models first.

With a env["rack.io"] that exposes an IO-ish object, then nothing
prevents developers from using EM.attach or Rev::IO.new on it, either.
If people like that, I'd be happy to include it EM and Rev-based
concurrency models for Rainbows! and add support for it in Sunshowers.

-- 
Eric Wong