[Web-SIG] PasteDeploy comments

[Jim Fulton]

On Mar 2, 2007, at 8:17 PM, Ian Bicking wrote:

> Jim Fulton wrote:
>>   What have you used global configuration data for?
>
> It's often meant for configuration that applies to many  
> components.  For instance, a "debug" value that applies widely (or  
> could also be applied locally).  Or information about where to  
> email errors, some logging information, etc.  E.g., you might give  
> a base directory for logging in global_conf, and an application  
> could pick that up and probably put it in a subdirectory there  
> (where if you configured it locally, you'd probably give the  
> application the full path of the log file).

I know what it's meant for.  I was asking what it was actually *used*  
for.  Is this truly useful?


>
>> - The semantics of paste.server_factory seem to be a little  
>> unclear. In particular, I *assume* that the return value is  
>> expected to block when run.  Is this true?  If so, then it makes  
>> it hard to have more  than one server.  I know that you aren't  
>> fond of the idea of having  multiple servers, but a lot of other  
>> folks seem to want it. :) In any case, the semantics of the return  
>> value need to be documented.
>
> paste.server_factory should be expanded, in part for what you are  
> proposing (starting multiple servers).

Cool

>   Also, it seems like there should be a better way to shut it down  
> than killing the entire process.  For instance, for performance  
> testing.

<shrug>  This doesn't seem important to me.

...

>> Overall, PasteDeploy looks very usable.  I'll probably find other  
>> issues when I actually try to use it.  One of my next projects wil  
>> be to look at how to use it in Zope.  zope.paste is a bit too much  
>> of a wedge.
>
> zope.paste, as I remembered it, didn't really seem to allow things  
> like instantiating multiple Zope applications.  But I can't  
> remember.  And that's not always feasible; Zope 2 is unlikely to  
> really support many truly separate instantiated applications, but  
> it could still support the basic configuration.

zope.paste tries very hard to minimize its impact on zope  
configuration.  It has to make a number of compromises to do this.   
It is impossible to run "truly separate" Python applications in the  
same process, for some definition of "truly separate" and  
"application".  separate WSGI applications will share common module  
definitions and shared module globals.  I can easily imagine separate  
Zope (2 & 3) applications that exposed separate object spaces or sets  
of procedural (as opposed to object-based) pages.


>> On a related note, I'll probably want to do process configuration  
>> in the same file that that PasteDeploy uses. This would likely  
>> include things like:
>> - interrupt-check-interval
>> - Log files
>> I guess there is nothing to prevent this.  I suspect that I'll  
>> also get a lot of resistence to moving this out of zope.conf. :/
>
> Yes, the container configuration.  (Incidentally, what exactly do  
> we call this thing we're proposing to make?)

I'm not sure we're initially proposing to make *a* thing. For  
starters I think we're exploring using the PasteDeploy-defined  
frameworks and to collaborate on sever testing.

I would call this the main program, but maybe other terms would be  
better.

>> Have you tried pointing logging.fileConfig at a cnfig file  
>> containing PasteDeplot sections?  I assume it would work.
>
> I haven't tried it, but I think Ben Bangert has started work on  
> that, using global_conf['__file__'] that way.  A more cohesive  
> logging story that included that would be nice.

I think this should be done by the main program (container/whatever)  
not by an application.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org