[Web-SIG] more comments on Paste Deploy
ianb at colorstudy.com
Sat Mar 3 22:06:07 CET 2007
Robert Brewer wrote:
> Jim Fulton wrote:
> > I believe, we're evaluating Paste Deploy at 2 levels:
> > 1. Can we agree on a standard set of entry points so
> > that WSGI applications can be combined automatically?
> > I think Paste Deploy provides at least good start on this.
> Yes, I think we can. And the ones in paste deploy are a good start (and
> end, for all I know). But if Ian's going to split Paste Deploy out into
> its own project (as he hinted), we should find a new namespace for them
> besides 'paste.*' soon.
Well, only if we use the entry points ;). Paste Deploy already supports
a couple overlapping entry points. It could support more, or a new
system could support those plus some more (I assume even if we implement
a new config file format here, I'll add support to Paste Deploy as well
for people who don't switch over immediately).
I don't think we should add any new names or prefixes until we've
solidly settled on what those entry points define. If we want to rename
the Paste Deploy entry point groups at that point, that's fine.
> > 2. Do we want to reuse it's configuration syntax.
> > On the subject of configuration format, I suppose this
> > is a matter of taste. I strongly prefer having fewer
> > configuration files, preferably one.
> In my head, we share a 'site daemon' among us, and a common 'webctl'
> front end to that daemon should use a single INI-style config file (but
> like Chad, I'm not sold on Paste's existing format). However, we should
> build the site daemon in such a way that each framework can drive it in
> framework-specific way, and if they wanted to layer their own config
> style on top of that interface, fine. This would make it easier for the
> various framework authors and users to explore tutorials, run tests, and
> deploy single-framework sites.
> In short, I'm pushing for:
> read conf -> apply conf -> del conf -> work with objects
> as opposed to the much more tightly-coupled and hard-to-use:
> read conf -> work with a mix of conf and objects forever
I definitely agree that we shouldn't pass big config objects to
applications (or servers or middleware or whatever). I don't really
like that global_conf['__file__'] gives you the filename; it's a little
vague what it really means when you are nesting several files, and it
can encourage hacky things. OTOH, if you want to fold your logging conf
in with your app conf, it provides a reasonably easy way to do that I
suppose. Anyway, besides one or two ways you can poke through, Paste
Deploy mostly does this.
Incidentally, one thing Paste Deploy doesn't really allow well is when
you have really complicated configuration. For instance, an application
like Trac has a big config file with lots of sections. One could argue
that it's *too* big, but it is what it is.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG