[Web-SIG] WSGI deployment use case

Phillip J. Eby pje at telecommunity.com
Tue Jul 26 02:15:05 CEST 2005


At 06:40 PM 7/25/2005 -0500, Ian Bicking wrote:
>But configuration and composition of multiple independent applications
>into a single process isn't.  I don't think we can solve these
>separately, because the Hard Problem is how to handle configuration
>alongside composition.  How can I apply configuration to a set of
>applications?  How can I make exceptions?  How can an application
>consume configuration as well as delegate configuration to a
>subapplication?  The pipeline is often more like a tree, so the logic is
>a little complex.  Or, rather, there's actual *logic* in how
>configuration is applied, almost all of which are viable.

We probably need something like a "site map" configuration, that can handle 
tree structure, and can specify pipelines on a per location basis, 
including the ability to specify pipeline components to be applied above 
everything under a certain URL pattern.  This is more or less the same as 
my "container API" concept, but we are a little closer to being able to 
think about such a thing.

Of course, I still think it's something that can be added *after* having a 
basic deployment spec.


>I can figure out a bunch of ad hoc and formal ways of accomplishing this
>in Paste; most of it is already possible, and entry points alone clean
>up a lot of what's there (encouraging a separation between how an
>application is invoked generally, and install-specific configuration).
>But with a more limited and declarative configuration it is harder.

But the tradeoff is greater ability to build tools that operate on the 
configuration to do something -- like James Gardner's ideas about 
backup/restore and documentation tools.


>Also when configuration is pushed into factories as keyword arguments,
>instead of being pulled out of a dictionary, it is much harder -- the
>configuration becomes unhackable.

But a **kw argument *is* a dictionary, so I don't understand what you mean 
here.



More information about the Web-SIG mailing list