From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.191.1 with SMTP id o1cs148610wff; Tue, 15 Dec 2009 03:16:08 -0800 (PST) Received: from mr.google.com ([10.229.111.83]) by 10.229.111.83 with SMTP id r19mr290757qcp.15.1260875766995 (num_hops = 1); Tue, 15 Dec 2009 03:16:06 -0800 (PST) Received: by 10.229.111.83 with SMTP id r19mr40922qcp.15.1260875765577; Tue, 15 Dec 2009 03:16:05 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.100.199 with SMTP id z7ls2455818qcn.0.p; Tue, 15 Dec 2009 03:16:03 -0800 (PST) Received: by 10.229.13.212 with SMTP id d20mr880437qca.16.1260875763005; Tue, 15 Dec 2009 03:16:03 -0800 (PST) Received: by 10.229.13.212 with SMTP id d20mr880436qca.16.1260875762974; Tue, 15 Dec 2009 03:16:02 -0800 (PST) Return-Path: Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by gmr-mx.google.com with ESMTP id 25si1320601qyk.3.2009.12.15.03.16.01; Tue, 15 Dec 2009 03:16:01 -0800 (PST) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.221.181 as permitted sender) client-ip=209.85.221.181; Received: by qyk11 with SMTP id 11so1861264qyk.13 for ; Tue, 15 Dec 2009 03:16:01 -0800 (PST) Received: by 10.224.34.231 with SMTP id m39mr269717qad.188.1260875761651; Tue, 15 Dec 2009 03:16:01 -0800 (PST) Return-Path: Received: from ?192.168.101.102? ([199.172.234.251]) by mx.google.com with ESMTPS id 7sm3488139qwf.44.2009.12.15.03.15.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 03:16:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows! From: James Tucker In-Reply-To: <20091215043758.GB29127@dcvr.yhbt.net> Date: Tue, 15 Dec 2009 11:15:57 +0000 Message-Id: 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> To: rack-devel@googlegroups.com X-Mailer: Apple Mail (2.1077) X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.221.181 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com X-Original-Sender: jftucker@gmail.com 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/6d68748f9a233b4c Sender: rack-devel@googlegroups.com List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: >>>> On 14 Dec 2009, at 00:23, Lakshan Perera wrote: >>>>> This is awesome! Thanks for coming up something like this, in a >>>>> short period of time. I hope this would be part of Rack, which >>>>> would enable all Ruby Frameworks to work effortlessly with >>>>> WebSockets. >>>>=20 >>>> 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 :-) >>>=20 >>> 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. >>=20 >> 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. >=20 > 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 Both of these options put significant restrictions on the ability to do = complex (and efficient) scheduling. 1. Prevents the ability for the request to begin processing = asynchronously to the receipt of the request body without a custom = future of some kind. Adding a future is not a bad solution, but, it's so = far out from everything else at the moment because the rack spec says = use an IO. The StringIO could be used as a future, however, the reality = is there's no way for the server to tell the app that the future is = ready for consumption. This is a total lack of proper encapsulation that = would be required for improved scheduling and IO handling. 2. This approach forces the application developer to be responsible for = buffering and scheduling - something which application authors typically = know nothing about. The result is common use of slurp approaches, and = sometimes even multiple reads of the same buffer. > I haven't used Thin with uploads much, but I do have apps that handle > lots of large uploads (via curl -T to make PUT requests) with Unicorn > and Mongrel before that. >=20 > StringIO isn't perfect (can't stat/select/chmod on it), but for > Rack tests it's plenty alright... Sure, for trivial, low efficiency, slurping, synchronously scheduled = work, it's fine, and I do use it for that quite frequently. > [1] - I admit to having a Unix bias here where > nearly everything is a file, or ought to be :) We're not stream processing here. It's a request/response cycle. And = they aren't files, they're sockets. Unix philosophy is good for the shell, but it doesn't extend well into = efficient systems. The simplest proof for this is the existence of = kqueue, epoll, completion ports, and eventlets. To optimise for efficiency or for performance (they needn't be the = same), it is absolutely required that abstractions move away from = strictly synchronous and external-lock scheduled IO (like group select = or per-socket select, etc). >=20 > --=20 > Eric Wong