[Web-SIG] more comments on Paste Deploy

[Lynn Rees]

 > 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 didn't propose that validation be in the config format. I proposed 
that the configuration parser, whatever config format it's parsing, pass 
the configuration data it extracts on to the next stage of the WSGI 
composition process in a standard format. The parser may or may not 
validate configuration data before it passes it on; decomposing WSGI 
composition into distinct and modular stages means that the rest of the 
composition process doesn't have to care.

 > I personally am quite happy with Paste Deploy using straight strings, 
 > not Python expressions or anything else that presumes to understand
 > values.

I don't disagree but whether to use strings or not is an implementation 
issue (Paste Deploy) and not a process issue (WSGI application 
composition). My proposal addressed the process, not the particular 
implementation.

 > 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)?

The message passing format is based on the following premise: 
ultimately, any configuration of a WSGI component involves 1) locating a 
Python routine and 2) passing some combination of arguments and/or 
keywords to it. The format:

(identifier, (args), {kwargs})

contains sufficient information to 1) identify a Python routine and 2) 
pass configuration data to it in a format it's hardwired to handle. 
Whether a collection of configuration directives for a group of WSGI 
components is passed on to the next stage of the composition process as 
a tuple or a dictionary e.g.

{identifier1:((args), {kwargs}, identifier2:((args), {kwargs})}

is a matter of complete indifference to me.

 > 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?

The use of "use" and the concept of a distinct dispatching stage are 
complementary. The dispatcher accesses a map of identifiers to adapters, 
fetches the adapter matching an identifier, and passes configuration 
data to it. The identifier could be the value specified by the "use" 
key. That's an implementation decision.

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

What's passed in the args tuple and kwargs dictionary is the internal 
business of either the configuration parser that kicks the process off 
and the adapter that receives it at the end. From the point of view of 
passing the data between stages in the composition process, the type of 
the container is the only type that matters. Most Python containers are 
type agnostic and I think that's a good principle to remain faithful to 
in an interop format.

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

Since I compose WSGI components by sequentially wrapping one component 
within another, a sequence is the most natural way to pass WSGI 
configuration around to me. However, dictionaries are fine with me.

I wouldn't necessarily enforce order in a config format per se. However, 
the point of breaking the composition process into distinct phases is so 
that I can use whatever config file format I wish and know that the WSGI 
component I'm configuring will receive the configuration data-lcr