> 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com