From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.191.1 with SMTP id o1cs255702wff; Thu, 17 Dec 2009 00:48:01 -0800 (PST) Received: from mr.google.com ([10.114.7.3]) by 10.114.7.3 with SMTP id 3mr1278218wag.9.1261039681286 (num_hops = 1); Thu, 17 Dec 2009 00:48:01 -0800 (PST) Received: by 10.114.7.3 with SMTP id 3mr255755wag.9.1261039679901; Thu, 17 Dec 2009 00:47:59 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.114.188.15 with SMTP id l15ls76884waf.3.p; Thu, 17 Dec 2009 00:47:58 -0800 (PST) Received: by 10.114.44.6 with SMTP id r6mr462158war.3.1261039678864; Thu, 17 Dec 2009 00:47:58 -0800 (PST) Received: by 10.114.44.6 with SMTP id r6mr462157war.3.1261039678837; Thu, 17 Dec 2009 00:47:58 -0800 (PST) Return-Path: Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by gmr-mx.google.com with ESMTP id 9si454463pxi.10.2009.12.17.00.47.58; Thu, 17 Dec 2009 00:47:58 -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 1EC261F449; Thu, 17 Dec 2009 08:47:58 +0000 (UTC) Date: Thu, 17 Dec 2009 00:47:57 -0800 From: Eric Wong To: rack-devel@googlegroups.com Subject: Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows! Message-ID: <20091217084757.GA17489@dcvr.yhbt.net> References: <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> <20091216221427.GA21033@dcvr.yhbt.net> <5571C7DA-A701-4775-9F56-84CE1E9EBD30@gmail.com> MIME-Version: 1.0 In-Reply-To: <5571C7DA-A701-4775-9F56-84CE1E9EBD30@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/11e9a6c31298f7f2 Sender: rack-devel@googlegroups.com List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=us-ascii Content-Disposition: inline James Tucker wrote: > Agreed. I'm not saying "must", but I would like to request that if > you're going to try and support asynchronous models, please do it for > real, rather than hacking it in the way we're having to in rack / thin > / flow / etc. The more hacks we end up with, the more people get the > impression that this is "the right way". As it is, the lack of > protocol - app layer separation in for example, eventmachine > applications is appalling, and something from which the community may > never recover. The same kind of history is about to repeat itself in > the async + long running cycle web areas - if it hasn't already gone > past the point of no return. I'm glad I'm not alone in feeling the current async add-ons in Rack servers are very hacky. I'll leave async callback support out of Sunshowers until we can have an async spec that's as elegant the rest of Rack. > Like I say, I could just be too much of an efficiency ideologist. If > you don't have the demand / desire for it, then you may not have a > good reason to put the effort in - certainly there's nothing else in > the middle-ground space that you're filling presently, so I don't > think you're "losing a significant market" by not doing so. As it is, > I know of a couple of handfuls of apps either in production or close > to production doing relatively high load async web work in ruby, and > those folks seem to have done alright with the nasty hack that is the > current async.callback and deferrable body apis. Bigger deterrents to > this area actually exist outside of the web server domain itself, as > the 1.2+ Thin api works just fine, by contrast, there's no ORM or > process framework for doing async work well, and the closest thing > there really is to a "nice" async api in ruby open source at present > is the sequel monkey patches that Aman published iirc with em-mysql. Heh, I don't know of a single public site using Rainbows! (in any form) nor Sunshowers in production, yet. It's winter right now and probably not the season for Rainbows! and Sunshowers :) > P.S. it's late, so i apologise if this is too wordy/vague. Nope, I pretty agree with everything you said and will look forward to a Rack 2.0 spec that covers async nicely. Meanwhile, I'll keep the focus on 1.9 Fibers since they're largely "good enough". -- Eric Wong