Sys Ppp wrote:
> In current realization of Rack::Builder the method :use dictates that
> middlewares must be instances of some class by internal invoking :new
> initializer.

A middleware module must have a "next module" to pass the call() request 
onto (otherwise it wouldn't be in the middle :-) So it makes sense to 
create an instance of the middleware class, with the "next module" being 
stored in an instance variable.

The complicated bit is that Builder has to create them in a backwards 
order so they wrap each other.

> module MiddleHello
>   def self.call env
>     invoke @app, env, self.method(:call), "#{self.class}: #{self}"
>   end

I see you are using a module instance variable here. This is fine except 
that it limits you to only using the same middleware once.

You may have a Rack setup which bundles multiple apps, e.g. using 
urlmap, all of which are using the same middleware - in which case 
you'll need multiple instances. Not doing this would severely limit the 
flexibility of middleware IMO.

> Of course we can remake the Builder or make a subclass from it. But can
> it cause conflicts with hostings where Rack is used for administration?

No, you're free to create your own alternative Builder implementation. 
After all, all it does is return an object which responds to #call. 
That's all you need to do.

I did look at this myself once - I wanted to be able to pass extra 
parameters to the middleware modules. But the problem was the deferred 
initialisation of the modules, which was required to build them in the 
inside-out order. I decided that it was simpler in such cases not to use 
middleware, but to construct the stack explicitly:

  run Foo.new(Bar.new(Baz.new))
-- 
Posted via http://www.ruby-forum.com/.