Re: Bloat?

[James Tucker <jftucker@gmail.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.