From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.204.72.79 with SMTP id l15cs795700bkj; Thu, 13 Aug 2009 15:27:16 -0700 (PDT) Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.150.11.1 as permitted sender) client-ip=10.150.11.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.150.11.1 as permitted sender) smtp.mail=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com; dkim=pass header.i=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com Received: from mr.google.com ([10.150.11.1]) by 10.150.11.1 with SMTP id 1mr2122643ybk.28.1250202435261 (num_hops = 1); Thu, 13 Aug 2009 15:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :received:received:received:received-spf:authentication-results :received:dkim-signature:domainkey-signature:received:received :message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:reply-to:sender:precedence:x-google-loop:mailing-list :list-id:list-post:list-help:list-unsubscribe:x-beenthere-env :x-beenthere; bh=jZOlI/mR+T7BN3/0ITc/EIbwwsVMeejlPaZ2lu5i6qs=; b=U5jC9Omc6/3jAU3YLzFAd0BncZ8fvu9BInh08lqUNUDw7uC+mOv9lc4bp/NmplFUJT SGN+9LPZhON1RDvY8SA6d38B8QnH3rM+lOQgU4V6GNTdykw1iznJXVd6DcxTsxEIQQlb DkBskrasE0YBCJXHoE/RP5ywgjoh+4KXT0HzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:received-spf:authentication-results :dkim-signature:domainkey-signature:message-id:from:to:in-reply-to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer:reply-to:sender:precedence:x-google-loop :mailing-list:list-id:list-post:list-help:list-unsubscribe :x-beenthere-env:x-beenthere; b=Hj5t8xh48gXY17D2N35pg7PHZ08Z227HtAu+4IAwUKv58QeGZaPrr26vYZft6bdgOk UEP9mjDiWOGEFyVSogWza73sp8JjZlifPAySfv7AhT7jM3PE0D6GKXRvI3i/ZqX9hkzM ATOiIcLX9fKh2QS9OpVNQupZnKUbCsHBQln/k= Received: by 10.150.11.1 with SMTP id 1mr304379ybk.28.1250202434879; Thu, 13 Aug 2009 15:27:14 -0700 (PDT) Received: by 10.176.48.40 with SMTP id v40gr1590yqv.0; Thu, 13 Aug 2009 15:27:03 -0700 (PDT) X-Sender: jftucker@gmail.com X-Apparently-To: rack-devel@googlegroups.com Received: by 10.210.79.3 with SMTP id c3mr632112ebb.12.1250202422755; Thu, 13 Aug 2009 15:27:02 -0700 (PDT) Received: by 10.210.79.3 with SMTP id c3mr632111ebb.12.1250202422727; Thu, 13 Aug 2009 15:27:02 -0700 (PDT) Return-Path: Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by gmr-mx.google.com with ESMTP id 16si166596ewy.7.2009.08.13.15.27.01; Thu, 13 Aug 2009 15:27:01 -0700 (PDT) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 209.85.219.207 as permitted sender) client-ip=209.85.219.207; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 209.85.219.207 as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass (test mode) header.i=@gmail.com Received: by ewy3 with SMTP id 3so1216142ewy.18 for ; Thu, 13 Aug 2009 15:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ummuimfgWyUodujIn8ZLgsF69tZR9zLgpF3+Jz7cpVs=; b=i/FGFMtnJ5wqPBH9b5v5hRUJZb9BEnebUB+Dg+ShezpMoiJNVM30xeIrOI+ydJQY58 1aXblQymG92lRHHIi2YUE0zlag/baTY3ecMNhs0xoT3mTBm2MfGvn/Q2/46uR/2cn18+ VhrmIMoUj3TXQyiRHQiJDVeGYwzGogaFhVq98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=m4tO7CE+BHm5F+Jk0hOIP4FQMlawlvyIkWJPyk3HZk/s5CXzf51vIQjoYTv5KNdwTY O5X1W3+ug14zGCt0HvNhxWKrqgW/8R/KT0Nk2VoWu9uWNa56g2RyaxikxGt7OkBYR90c Se2aZq8IqJG9dSoFUNRMPVHzICkrJjX1H/p3E= Received: by 10.216.87.209 with SMTP id y59mr297840wee.21.1250202421380; Thu, 13 Aug 2009 15:27:01 -0700 (PDT) Return-Path: Received: from ?192.168.1.213? (bb-87-81-237-21.ukonline.co.uk [87.81.237.21]) by mx.google.com with ESMTPS id t12sm1014199gvd.14.2009.08.13.15.26.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 15:27:00 -0700 (PDT) Message-Id: From: James Tucker To: rack-devel@googlegroups.com In-Reply-To: <2a8d4a710908131219m47596a1dr8a943be32eb1030f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Bloat? Date: Thu, 13 Aug 2009 23:26:52 +0100 References: <2a8d4a710908131004i2cef7cb7lc0be17ae7fe7619f@mail.gmail.com> <2a8d4a710908131219m47596a1dr8a943be32eb1030f@mail.gmail.com> X-Mailer: Apple Mail (2.936) Reply-To: rack-devel@googlegroups.com Sender: rack-devel@googlegroups.com Precedence: bulk X-Google-Loop: groups Mailing-List: list rack-devel@googlegroups.com; contact rack-devel+owner@googlegroups.com List-Id: List-Post: List-Help: List-Unsubscribe: , X-BeenThere-Env: rack-devel@googlegroups.com X-BeenThere: rack-devel@googlegroups.com On 13 Aug 2009, at 20:19, Matt Todd wrote: > Great feedback! > > 1. Lot of disagreement here, and lots of valid points. To clarify, > the point wasn't runtime bloat (which is not a problem with Rack) > but with the overall package bloat. I tend to agree that runtime > bloat is much more severe than package bloat, and that Rack is > hardly bloated even considering. > > The question needs to be asked, though... are there things in Rack's > library that could be better elsewhere? I mention rack-more, and > many don't like this, which is fine. I think of rack-contrib to be > much like rack-more already, and like that some things are there > instead of in Rack's core library. Certainly, and I think the key question is usage frequency. The important consideration is that running two gems is significantly more overhead than a single gem. The observation is that if the most common use case after such changes involves running two or more gems, then the changes have introduced storage, packaging, maintenance, and runtime bloat. Loading gems (on 1.8) is not at all 'bloat free', in fact, if you check, you'll find that the gemspec details when loaded, live for quite an extended period of time in the application boot and run cycle. I wrote about this back in 2007, and to date, it has not changed (for 1.8). On 1.9 the gem_prelude shim can aid the situation, however, when there are gems in the system that use file discovery plugin loads, then all these gains are lost, too. > 2. The point of this was to elaborate on the question "are there > things in Rack's library that could be better elsewhere?" by > starting with the minimum. Rack::Lint is, as Ryan points at, the > wrong starting point because we still want to support middleware and > all of the server handlers and framework adapters as well as > Rack::Request and Rack::Response. > > I think Yehuda understood this with his recommendations on > improvements to these last two. What else can we minimize and defer > to the implementers using Rack instead of doing it ourselves? I agree, however, as I've otherwise said, it's also important to consider real world profiles for such improvements. If the real improvements are minor, but the change in complexity is high, then time might be better spent donating to the core language than to micro- optimising frameworks that are currently very simple and easy to understand and maintain. > Should Rack concern itself with much more than a minimal > implementation covering these handlers, adapters, request/response > interfaces, and middleware functionality? I can only re-iterate the common use case statement, and I won't claim to know what that is, but I will make keen the observation that "most users" don't tend to be signed up to every mailinglist, so polling for such information may be difficult - this aspect may require further thought and discussion. > No dictating or anything quite so grave here, just raising the > discussion. Absolutely, discussion is worthwhile.