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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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