[Web-SIG] more comments on Paste Deploy
ianb at colorstudy.com
Sat Mar 3 22:37:52 CET 2007
L.C. Rees wrote:
>> Sure, as long as Paste Deploy's config syntax is optional for
>> whatever-we're-building. :^)
> Some of the pain and angst over choosing one solution to the WSGI
> application composition problem could be treated by dividing the
> composition process into (at least) three parts:
> 1. Configuration parsing
> Configuration information is read from multiple files or one big file
> all at once (something ConfigParser in the standard library, for
> example, already has support for) or selectively. The information,
> stored in whatever format (INI, Python, even XML, pick your poison),
> is parsed (with optionally validation) into a uniform internal Python
I don't think we should have any validation in the config format (except
for basic syntax, of course). Doing validation is just too hard, and
leads to a rather complex config framework. I think some of the
problems with ZConfig come back to this.
I personally am quite happy with Paste Deploy using straight strings,
not Python expressions or anything else that presumes to understand values.
> The internal format would be a sequence of tuples. Each tuple
> would contain three elements:
> a. An identifier consisting of tuple that contains two elements, an
> (optional) qualifying prefix and a more specific identifier.
> b. Configuration parameters that have been parsed into a tuple of
> positional arguments.
> c. Configuration parameters that have been parsed into a dictionary of
> keyword arguments.
I'm confused here. Can you give an example of what this data would look
like for something simple? (E.g., a blog app) How does this different
or better than a flat dictionary of strings (which is basically what
Paste Deploy provides)?
> 2. Dispatching
> A dispatcher would take the sequence of tuples from the parser and
> resolve the identifier to an adapter. The dispatcher would then strip
> out the identifier, and pass a tuple containing the tuple of
> positional arguments the dictionary of keyword arguments to the
> Different identifier schemes could be accommodated by the same
> dispatcher as needed.
I'm not sure what you are describing here. Is this like in Paste
Deploy, we strip out the "use" key to find the entry point?
> 3. Adapting
> The adapter would be responsible for taking the configuration data in
> the tuple passed to it by the dispatcher and returning a configured
> WSGI application.
> An approach that decomposes the WSGI application composition process
> into distinct stages would accommodate different approaches to each
> stage of the composition process while allowing interoperability
> similar to how WSGI allows heterogeneous Python web applications to
> live together in (greater) peace and harmony-lcr
In some ways we can, in some ways we can't. For instance, a config file
format that produces integers, lists, etc., is a bit hard to reconcile
with a separate format that only produces strings. (If consumers always
special-case strings this isn't so bad, but if you get used to getting
non-strings you are less likely to do that.) Also, is order relevant?
It isn't in dictionaries, but could be in a file format, but probably
wouldn't be in a database. We have to come up with some lowest common
denominator. And having done that, we can support *some* set of config
formats or data sources, but a bunch of formats will seem superfluous,
as any added value they might provide will be useless since it can't be
In this sense, while the entry points can be mostly discussed regardless
of the config format, it's not entirely true -- you have to keep at
least some set of config formats in your head at the same time as you
are discussing the entry points.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG