[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
More information about the Web-SIG