Lately I've been thinking about the role of Paste and WSGI and whatnot. Much of what makes a Paste component Pastey is configuration; otherwise the bits are just independent pieces of middleware, WSGI applications, etc. So, potentially if we can agree on configuration, we can start using each other's middleware more usefully.
I think we should avoid questions of configuration file syntax for now. Lets instead simply consider configuration consumers. A standard would consist of: * A WSGI environment key (e.g., 'webapp01.config') * A standard for what goes in that key (e.g., a dictionary object) * A reference implementation of the middleware * Maybe a non-WSGI-environment way to access the configuration (like paste.CONFIG, which is a global object that dispatches to per-request configuration objects) -- in practice this is really really useful, as you don't have to pass the configuration object around. There's some other things we have to consider, as configuration syntaxes do effect the configuration objects significantly. So, the standard for what goes in the key has to take into consideration some possible configuration syntaxes. The obvious starting place is a dictionary-like object. I would suggest that the keys should be valid Python identifiers. Not all syntaxes require this, but some do. This restriction simply means that configuration consumers should try to consume Python identifiers. There's also a question about name conflicts (two consumers that are looking for the same key), and whether nested configuration should be preferred, and in what style. Note that the standard we decide on here doesn't have to be the only way the object can be accessed. For instance, you could make your configuration available through 'myframework.config', and create a compliant wrapper that lives in 'webapp01.config', perhaps even doing different kinds of mapping to fix convention differences. There's also a question about what types of objects we can expect in the configuration. Some input styles (e.g., INI and command line) only produce strings. I think consumers should treat strings (or maybe a special string subclass) specially, performing conversions as necessary (e.g., 'yes'->True). Thoughts? -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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