Middleware and Rack::Request

[Yehuda Katz]

With Chris' proposal a few days ago, we now have a way to easily lazy-load specific types of processing. I think it's worthwhile to consider what sorts of things belong in middleware and what sorts of things should be added to Rack::Request.

It seems to me that anything that could potentially be lazy-loaded should go on Rack::Request, because middleware would either require mandatory loading or a DeferredHash kind of hack. An obvious thing that comes to mind is params parsing. It would be easy enough to use the DeferredHash hack to make it a middleware, but just having Rack::Request#params means that you can keep that sort of logic in the object (where it can be more easily managed).

Another potential benefit of keeping it on the object could be perf (having very large numbers of middlewares, each doing very simple things, could get non-performant pretty quickly).

What do people think?

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Michael Fellinger]

I'm using a subclass of Rack::Request for the things you mention
here... extended parameter parsing, building urls, reasoning about the
stuff in env in general.
Middleware is IMHO for things that actually modify env and must be
used with care.

^ manveru

[Scytrin dai Kinthra]

On some of the middlewares that I've been working on, I'll have a
RequestMethods module that I'll include into a Rack::Request. Usually
with cached or lazy-loading methods for some of the env alterations or
values that the middleware works on.

--
stadik.net