From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.204.72.79 with SMTP id l15cs785071bkj; Thu, 13 Aug 2009 12:20:40 -0700 (PDT) Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.95.15 as permitted sender) client-ip=10.100.95.15; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.95.15 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.100.95.15]) by 10.100.95.15 with SMTP id s15mr1764226anb.26.1250191238761 (num_hops = 1); Thu, 13 Aug 2009 12:20:38 -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:mime-version:received :in-reply-to:references:from:date:message-id:subject:to:content-type :reply-to:sender:precedence:x-google-loop:mailing-list:list-id :list-post:list-help:list-unsubscribe:x-beenthere-env:x-beenthere; bh=gpFQAj5ho1OERDio8VzPbwV11P8zhwQb1k/GDsiCJaw=; b=UC3uDCPdS1jIamzIvRrtTrWVIgVFlsaWWtiwjpF7sp57NwRSC54WOiiMoDJsM+bORC wAYZ1P5FHwxkBi9bAPtlOukdlWG77rNXCpgg0T5KBdRrxGSxIh6Co/JgaBB1i4XoDnxr KRoHa2q/exjK82KThnRcEST3L+C6rK0OZRYy8= 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:mime-version:in-reply-to :references:from:date:message-id:subject:to:content-type:reply-to :sender:precedence:x-google-loop:mailing-list:list-id:list-post :list-help:list-unsubscribe:x-beenthere-env:x-beenthere; b=CBVyHRoSxMLQwi3YvJWXybGoilQ/rpThE9eDNMB1AppDcy5WVu4nyE9Ja61ZUGpj3S lqfn03EJNz8knUK95H3PYKdIrZIbs47s+5MzkcZVs1qLseQHYTrtUpoR7xSVT3GMjFjt QiD+R8PX7jZ4uzGXe2l3kAeBa8WO4EONHp/dM= Received: by 10.100.95.15 with SMTP id s15mr255506anb.26.1250191238384; Thu, 13 Aug 2009 12:20:38 -0700 (PDT) Received: by 10.177.102.22 with SMTP id e22gr1588yqm.0; Thu, 13 Aug 2009 12:20:30 -0700 (PDT) X-Sender: chiology@gmail.com X-Apparently-To: rack-devel@googlegroups.com Received: by 10.90.19.13 with SMTP id 13mr501578ags.2.1250191224732; Thu, 13 Aug 2009 12:20:24 -0700 (PDT) Received: by 10.90.19.13 with SMTP id 13mr501546ags.2.1250191219298; Thu, 13 Aug 2009 12:20:19 -0700 (PDT) Return-Path: Received: from mail-yx0-f202.google.com (mail-yx0-f202.google.com [209.85.210.202]) by gmr-mx.google.com with ESMTP id 15si85755gxk.4.2009.08.13.12.20.18; Thu, 13 Aug 2009 12:20:18 -0700 (PDT) Received-SPF: pass (google.com: domain of chiology@gmail.com designates 209.85.210.202 as permitted sender) client-ip=209.85.210.202; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of chiology@gmail.com designates 209.85.210.202 as permitted sender) smtp.mail=chiology@gmail.com; dkim=pass (test mode) header.i=@gmail.com Received: by yxe40 with SMTP id 40so1352878yxe.23 for ; Thu, 13 Aug 2009 12:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=4hWhkS+CC2/wE6UAceep/96G3sLgpGpxaNkKFXAjkr4=; b=jPWgZB7Qsp0+o3JfHX/m3GikBjOLqJ7CAEXHYU5UXuThNMasUsHM5knrB+B5wptFXG gxPdkKsAT+65kk1+BEh8iTBed8OrF0abjd0BLdY7ksE5ZMEsXNB9N9hEpyJaBsJOElyy 2xRNSVSOzyr4qj3xjPvYHsdTNccyJBuyoP0+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=iJft+7MRdViN259QgBtvZt/PITxSn9eArr/AGQlm0olvRufj2nXKAPiGyVzIM7eMCW /UYgdDPLNs/Bry5SrpuwFFh39/Hy6ejZhQ6Is2EPHCAyZTFDNQIEwxU8Y8CEO8P6IkeK hxjqa698Ipt84f8Ulc1i411hjJgqCoP/1skQU= MIME-Version: 1.0 Received: by 10.150.124.4 with SMTP id w4mr1839238ybc.18.1250191218169; Thu, 13 Aug 2009 12:20:18 -0700 (PDT) In-Reply-To: References: <2a8d4a710908131004i2cef7cb7lc0be17ae7fe7619f@mail.gmail.com> From: Matt Todd Date: Thu, 13 Aug 2009 15:19:58 -0400 Message-ID: <2a8d4a710908131219m47596a1dr8a943be32eb1030f@mail.gmail.com> Subject: Re: Bloat? To: rack-devel@googlegroups.com Content-Type: multipart/alternative; boundary=000e0cd4845e75d78404710ad3b0 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 --000e0cd4845e75d78404710ad3b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. 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? Should Rack concern itself with much more than a minimal implementation covering these handlers, adapters, request/response interfaces, and middleware functionality? No dictating or anything quite so grave here, just raising the discussion. Cheers! Matt On Thu, Aug 13, 2009 at 3:01 PM, Ryan Tomayko wrote: > > On Thu, Aug 13, 2009 at 10:04 AM, Matt Todd wrote: > > I was talking to a friend of mine yesterday and he mentioned that thought > > the Rack package itself seemed to be slightly bloated by things like > Basic > > Auth et al. He mentioned two things I thought were interesting and I > wanted > > to get your feedback on it: > > > > 1. Like Merb, Rack probably could benefit from using a core and more > > separation of functionality, and > > Matt, that's just crazy talk. > > > 2. Rack core should only include what's necessary for Rack::Lint to > validate > > a basic application at minimum. > > You actually don't need Rack the library to write Rack apps. The Rack > SPEC uses only core Ruby data structures to define the basic protocol. > Rack would include only Rack::Lint at that point. > > Thanks, > Ryan > -- Matt Todd Highgroove Studios www.highgroove.com cell: 404-314-2612 blog: maraby.org Scout - Web Monitoring and Reporting Software www.scoutapp.com --000e0cd4845e75d78404710ad3b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 t= hat 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 thi= ngs in Rack's library that could be better elsewhere? I mention rack-mo= re, 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 instea= d of in Rack's core library.

2. The point of this was to elaborate on the question &= quot;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 Ra= ck::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?

Should Rack concern itself with much more than a minimal impleme= ntation covering these handlers, adapters, request/response interfaces, and= middleware functionality?

No dictating or anythin= g quite so grave here, just raising the discussion.

Cheers!

Matt



On Thu, Aug 13, 2009 = at 3:01 PM, Ryan Tomayko <r@tomayko.com> wrote:

On Thu, Aug 13, 2009 at 10:04 AM, Matt Todd<chiology@gmail.com> wrote:
> I was talking to a friend of mine yesterday and he mentioned that thou= ght
> the Rack package itself seemed to be slightly bloated by things like B= asic
> Auth et al. He mentioned two things I thought were interesting and I w= anted
> to get your feedback on it:
>
> 1. Like Merb, Rack probably could benefit from using a core and more > separation of functionality, and

Matt, that's just crazy talk.

> 2. Rack core should only include what's necessary for Rack::Lint t= o validate
> a basic application at minimum.

You actually don't need Rack the library to write Rack apps. The = Rack
SPEC uses only core Ruby data structures to define the basic protocol.
Rack would include only Rack::Lint at that point.

Thanks,
Ryan



--
Matt Todd
Hig= hgroove Studios
www.highgroove.com=
cell: 404-314-2612
blog: maraby.or= g

Scout - Web Monitoring and Reporting Software
www.scoutapp.com
--000e0cd4845e75d78404710ad3b0--