From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.142.191.1 with SMTP id o1cs266051wff; Thu, 17 Dec 2009 03:54:38 -0800 (PST) Received: from mr.google.com ([10.229.114.218]) by 10.229.114.218 with SMTP id f26mr660509qcq.42.1261050877970 (num_hops = 1); Thu, 17 Dec 2009 03:54:37 -0800 (PST) Received: by 10.229.114.218 with SMTP id f26mr93361qcq.42.1261050876572; Thu, 17 Dec 2009 03:54:36 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.229.44.36 with SMTP id y36ls75071qce.3.p; Thu, 17 Dec 2009 03:54:35 -0800 (PST) Received: by 10.229.101.74 with SMTP id b10mr332413qco.8.1261050875221; Thu, 17 Dec 2009 03:54:35 -0800 (PST) Received: by 10.229.101.74 with SMTP id b10mr332412qco.8.1261050875185; Thu, 17 Dec 2009 03:54:35 -0800 (PST) Return-Path: Received: from mail-qy0-f197.google.com (mail-qy0-f197.google.com [209.85.221.197]) by gmr-mx.google.com with ESMTP id 19si475671qyk.12.2009.12.17.03.54.34; Thu, 17 Dec 2009 03:54:34 -0800 (PST) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.221.197 as permitted sender) client-ip=209.85.221.197; Received: by qyk35 with SMTP id 35so858820qyk.19 for ; Thu, 17 Dec 2009 03:54:34 -0800 (PST) Received: by 10.224.23.10 with SMTP id p10mr1559241qab.72.1261050870656; Thu, 17 Dec 2009 03:54:30 -0800 (PST) Return-Path: Received: from ?192.168.101.102? ([199.172.234.251]) by mx.google.com with ESMTPS id 7sm5365627qwf.44.2009.12.17.03.54.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 03:54:29 -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: <20091217084757.GA17489@dcvr.yhbt.net> Date: Thu, 17 Dec 2009 11:54:27 +0000 Message-Id: <14E7F86D-E27F-4A28-9A2D-AF339B3CBB70@gmail.com> 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> <20091217084757.GA17489@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.197 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/8e10dc23320dd888 Sender: rack-devel@googlegroups.com List-Unsubscribe: , List-Subscribe: , Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 17 Dec 2009, at 08:47, Eric Wong wrote: > 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. >=20 > 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. Yup, this is part of the reason I refused to release my Thin patches for = such a long time. They're not graceful at all. Unfortunately, after some = of the heavy lifters had been using it in production for a while, and it = was becoming a core component of some of the nanite infrastructure, the = amount of noise it was causing in my inbox overrode my desire to hold = back the unfortunate API from the public as a whole. It's getting an = increasing amount of attention, for better or worse at the moment. >> 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. >=20 > 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 :) :D I don't know if you follow the Thin mailinglist, but there's a = discussion relating to some of this stuff going on over there that you = might find useful to read through, just from the point of view of how = general community members tend to approach the idea of async, and the = common misconceptions etc. My really long term goal is to get the APIs = down to something simple enough that these issues don't come up, but = part of this is also the requirement for a new breed of framework that's = not built around inherently synchronous ORM systems. >> P.S. it's late, so i apologise if this is too wordy/vague. >=20 > 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". Absolutely, I know that oldmoe has had some great success using them in = NeverBlock, and who knows, if ruby can be made to be more efficient at = stack wrangling one day, then maybe they could defeat the async = approach. Certainly for the foreseeable decades, that's not going to = happen though :) I'll be sure to include you in any future discussions on the APIs = discussed. >=20 > --=20 > Eric Wong