[Web-SIG] more comments on Paste Deploy

[Ian Bicking]

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

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
> adapter.
> 
> 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 
relied upon.

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