From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.191.1 with SMTP id o1cs234848wff; Wed, 16 Dec 2009 14:14:35 -0800 (PST) Received: from mr.google.com ([10.91.95.6]) by 10.91.95.6 with SMTP id x6mr2857590agl.18.1261001674152 (num_hops = 1); Wed, 16 Dec 2009 14:14:34 -0800 (PST) Received: by 10.91.95.6 with SMTP id x6mr387305agl.18.1261001672770; Wed, 16 Dec 2009 14:14:32 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.204.16.73 with SMTP id n9ls336383bka.3.p; Wed, 16 Dec 2009 14:14:30 -0800 (PST) Received: by 10.204.160.141 with SMTP id n13mr58511bkx.30.1261001669390; Wed, 16 Dec 2009 14:14:29 -0800 (PST) Received: by 10.204.160.141 with SMTP id n13mr58510bkx.30.1261001669364; Wed, 16 Dec 2009 14:14:29 -0800 (PST) Return-Path: Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by gmr-mx.google.com with ESMTP id 18si123530bwz.1.2009.12.16.14.14.28; Wed, 16 Dec 2009 14:14:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of normalperson@yhbt.net designates 64.71.152.64 as permitted sender) client-ip=64.71.152.64; Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id 800141F50B; Wed, 16 Dec 2009 22:14:27 +0000 (UTC) Date: Wed, 16 Dec 2009 14:14:27 -0800 From: Eric Wong To: rack-devel@googlegroups.com Subject: Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows! Message-ID: <20091216221427.GA21033@dcvr.yhbt.net> References: <20091211201958.GD2121@dcvr.yhbt.net> <20091213205355.GB30229@dcvr.yhbt.net> <20091214184227.GB12789@dcvr.yhbt.net> <102BE9BA-FC74-4C5C-A37B-A526C0E7A010@gmail.com> <20091215043758.GB29127@dcvr.yhbt.net> <20091215213225.GA15190@dcvr.yhbt.net> <2C04E92E-EFF1-400A-9FE8-ADF58AE9D8C9@gmail.com> MIME-Version: 1.0 In-Reply-To: <2C04E92E-EFF1-400A-9FE8-ADF58AE9D8C9@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of normalperson@yhbt.net designates 64.71.152.64 as permitted sender) smtp.mail=normalperson@yhbt.net X-Original-Sender: normalperson@yhbt.net Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/1214d460ed982748 X-Message-Url: http://groups.google.com/group/rack-devel/msg/d8774c2c4164a40c Sender: rack-devel@googlegroups.com List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=us-ascii Content-Disposition: inline James Tucker wrote: > On 15 Dec 2009, at 21:32, Eric Wong wrote: > >> On 15 Dec 2009, at 04:37, Eric Wong wrote: > >>> James Tucker wrote: > >>>> On 14 Dec 2009, at 18:42, Eric Wong wrote: > >>>>> James Tucker 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