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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com