[Web-SIG] Standardized configuration

[Chris McDonough]

On Sat, 2005-07-23 at 21:57 -0400, Phillip J. Eby wrote:
> > > 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. 

FWIW, I think I fall somewhere between you and Ian on this, and maybe
more towards you.

I believe that there are services that are usefully composed as
middleware ("oblivious" things like XSL renderering and caches).  But
sessioning and auth services and whatnot I wouldn't put into middleware.
Instead, I'd use some service library that would have a much nicer
configuration API.  But none of that should really be described within
the deployment spec, so I haven't done so.

I'm trying to be sensitive of Ian's desire to use middleware for all
kinds of services.  I also do think there is a place for middleware, so
it's useful to be able to compose pipelines declaratively even if they
are terribly simple.  OTOH, if I set up an actual deployment for a
customer, it would rarely consist of more than one or two gateways and
then the application and many times it would just be the application if
I had no need for "oblivious" middleware apps in the pipeline.

Anyway, back to the nitty gritty of config, I'd rather just use
ConfigParser "as is" right now than to come up with another .ini parser
that preserves section ordering, thus the non-dependence on ordering
within the deployment file.

>  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.

I agree.

> 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 fine by me.

> 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)

Yes.  I hadn't thought about managing service context based on
containment like this (and I like that), but to me, this is a services
registration all the same.

> 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.

I'd agree.  I'd only like to use the deployment spec to compose a
pipeline out of very simple oblivious middleware apps and a single
endpoint app.

> 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.

+1.  This is the main reason that I'm trying to resist putting
arbitrarily complex configuration into the deployment file.  I don't
think there's anything about the proposal I sent over the other day that
advocates complexity in the config format.  As far as I'm concerned,
there isn't much configuration for middleware, and when there is, they
can use envvars or a separate config file.  Most of the more complex
configuration I'd tend to do via a services library.

- C