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 colorstudy.com | http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com
|
