[Web-SIG] more comments on Paste Deploy

[Ian Bicking]

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