                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of joshp...@gmail.com designates 209.85.198.229 as permitted sender) client-ip=209.85.198.229;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=PJHC6Iy5Fr5vNBBSLhwX0p9iEbDNKpVwt23/H4V2BA7hEWLq7WFshCJCfAg0YL9J3i
         OduSK/Y0Ohaknr3RJjd5WzcMHiQOZ69YDteEplGq7t/WasWmORYr5VlerxsBmvxRL5i5
         wxIMhlos7PKtacS3GE8S0v0VgG0AKlITB2fYQ=
Message-ID: <1c5622660812241527t125930f2s2c04bb2e10be4...@mail.gmail.com>
Date: Wed, 24 Dec 2008 17:27:01 -0600
From: "Joshua Peek" <j...@joshpeek.com>
Sender: joshp...@gmail.com
To: rack-devel@googlegroups.com
Subject: Re: Lazy-loaded and memoized processing
In-Reply-To: <2a8d4a710812241456t156addf0ocf3ae51e7f226...@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <245fb4700812241435j63e293b5q4f8d4f15af7cb...@mail.gmail.com>
	 <2a8d4a710812241456t156addf0ocf3ae51e7f226...@mail.gmail.com>

Tiny detail, override new for better backwords compat and a nicer API I think.

On 12/24/08, Matt Todd <chiol...@gmail.com> wrote:
> Effectively...
>
> def Rack::Request.from(env)
>   unless env['rack.request']
>     env['rack.request'] = Rack::Request.new(env)
>   end
>   env['rack.request']
> end
>
> Hmm?
>
> Matt
>
>
> On Wed, Dec 24, 2008 at 5:35 PM, Yehuda Katz <wyc...@gmail.com> wrote:
>
>> Hey guys. I just wanted to post about a problem I've been working through
>> and a potential solution to get some feedback. Effectively, there's a
>> bunch
>> of related code that handles various processing of the Rack environment.
>> However, much of this processing is triggered by requests by the user, and
>> can be expensive. The current recommended approach is to create a
>> middleware
>> that processes the rack environment as needed, and stuff the results back
>> into the environment hash. This works fine for cases where you know the
>> processing will be needed, but not as well for cases where the processing
>> is
>> to be used optionally by a user downstream in the middleware chain. Before
>> rack, the approach both Rails and Merb used was to do that processing in a
>> Request object that could process the environment only when a specific
>> accessor was called. Some examples include "method", a 10-line method in
>> Merb, various parameter parsing (which can be quite expensive), remote_ip
>> (another function that is longer than it seems like is reasonable), and it
>> goes on and on. What is desirable is for the appropriate processing to be
>> done when required, and only once. Whether or not the user is in the
>> Rails/Merb application or Rack middleware should not affect this (the user
>> should have access to any required processing). Unfortunately, since the
>> Rack environment is required to be a "real" Hash, it's not possible to
>> modify the environment to support lazy-loaded and memoized processing. One
>> option we *considered* was a middleware that did something like
>> env["rack.request_obj"] = Rack::Request.new(env). This would provide the
>> benefits of a logical object for the request without breaking Rack
>> conventions. However, after emailing Chris to explain this problem, he
>> suggested an even better (to my eyes) solution: > I think I have a better
>> idea for this... we could make > Rack::Request.new cache the request
>> object
>> in the env itself(!) and > just return it when it was created and
>> calculated
>> already. This would > be backward compatible, efficient, and not expose
>> any
>> details on the > implementation. I love this idea and would love to get
>> some
>> feedback on it. Thanks a ton,
>>
>> --
>> Yehuda Katz
>> Developer | Engine Yard
>> (ph) 718.877.1325
>>
>
>
>
> --
> Matt Todd
> Highgroove Studios
> www.highgroove.com
> cell: 404-314-2612
> blog: maraby.org
>
> Scout - Web Monitoring and Reporting Software
> www.scoutapp.com
>


-- 
Joshua Peek