[Web-SIG] Standardized configuration

[Phillip J. Eby]

At 08:41 PM 7/23/2005 -0400, Chris McDonough wrote:
>On Sat, 2005-07-23 at 20:21 -0400, Phillip J. Eby wrote:
> > At 08:08 PM 7/23/2005 -0400, Chris McDonough wrote:
> > >Would you maybe rather make it more explicit that some apps are also
> > >gateways, e.g.:
> > >
> > >[application:bleeb]
> > >config = bleeb.conf
> > >factory = bleeb.factory
> > >
> > >[filter:blaz]
> > >config = blaz.conf
> > >factory = blaz.factory
> >
> > That looks backwards to me.  Why not just list the sections in pipeline
> > order?  i.e., outermost middleware first, and the final application last?
> >
> > For that matter, if you did that, you could specify the above as:
> >
> >      [blaz.factory]
> >      config=blaz.conf
> >
> >      [bleeb.factory]
> >      config=bleeb.conf
>
>Guess that would work for me, but out of the box, ConfigParser doesn't
>appear to preserve section ordering.  I'm sure we could make it do that.
>Not a dealbreaker either, but if you ever did want a way to
>declaratively configure something in the config file like the generic
>"decision middleware" I described in that message, this wouldn't really
>work.  I hadn't described it yet, but I can also imagine declaring
>multiple pipelines in the config file and using decision middleware to
>choose the first app in the next pipeline (as opposed to just an app).

I consider this a YAGNI, myself.  But then again, most of the pipeline 
stuff seems like a YAGNI to me.

Probably that's because everything you guys are talking about implementing 
with pipelines of middleware, I'd use a single generic function for.  If I 
was wrapping oblivious or legacy apps, I'd just make one middleware object 
that then calls the generic function to do any and all dynamic 
requirements, because it would only take a little bit of syntax sugar to 
implement "configuration" scripts like:

     use_auth("/some/subdir", some_auth_service)
     mount_app("/other/path", some_app_object)

etc.  So, all the time spent on coming up with an uglier, less-powerful 
pseudo-framework to simulate these capabilities using crude .ini files and 
poking stuff into environ seems kind of wasteful to me, versus defining a 
powerful API to -- dare I say it -- "paste" applications together.  :)

However, such an API deserves to be both powerful and easy-to-use, not 
kludged together with .ini syntax.

That's not saying I don't think WSGI should have a deployment configuration 
format based on .ini syntax -- I still do!  I just don't think it should 
even attempt to allow anything complex.  A simple static pipeline and some 
server-defined and WSGI-defined options will do nicely for the "simple 
things are simple" case, and a Python file will do nicely for all the 
"complex things are possible" cases.

That's why I'd like to see this effort split into two parts: 1) simple 
deployment, and 2) a "pasting" API whose entire purpose in life is to 
stack, route, and multiplex "middleware" and "applications" without having 
to explicitly manage a pipeline.

This API would use *specificity* as a basis for establishing pipelines, 
because it's not at all scalable (developer-wise) to set up pipelines on a 
URL-by-URL basis for a complex application -- especially for applications 
that aren't page-based!  Usually, you'll need some kind of pipeline 
inheritance to manage that sort of thing.

There is little reason, however, why you can't configure a significant 
portion of a URL space using a single WSGI component, using an appropriate 
mechanism.  For example, recasting my earlier example:

     def factory(container):
         container.use_auth("some/subdir", some_auth_service)
         container.mount_app_factory("other/path", some_app_factory)

Then, the 'mount_app_factory()' call could invoke 
'some_app_factory(subcontainer)' where 'subcontainer' is a wrapper that 
prepends 'other/path' to URLs before delegating to 'container'.

In other words, once you have this "container API", there's no reason not 
to just use it to implement the whole stack in a single middleware object.

Anyway, this is why I think there should be a "WSGI Services" and/or "WSGI 
Container API" spec, distinct from a "WSGI Deployment Metadata" 
spec.  These two spheres are both valuable, but I think it'll take longer 
to get a "deployment" spec if we mix "container API" stuff into it -- and 
get a much less useful container API than if we set our minds on making a 
good container API, rather than a souped-up deployment descriptor.