[Web-SIG] Standardized configuration
Phillip J. Eby
pje at telecommunity.com
Sun Jul 24 03:57:13 CEST 2005
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:
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:
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.
More information about the Web-SIG