> Currently you configure Zope via a combination of z2.py switches and
> envvars. There are currently 40 Zope environment variables and 22 z2.py
Well you won't hear a peep out of me if z2.py gets the axe, as I
mentioned I stopped using it long ago in favor of something that was
only 39 lines and only did exactly what I needed and nothing more.
> I feel that it's just as simple (or maybe simpler) to look in a config
> file. The Zope config file will be stored on the filesystem (not in the
> ZODB), and it's in a format much like an Apache config file, so no ZMI
> or custom client stuff will be necessary. There will be tools provided
> to parse the config file if necessary.
Yes, but config files lie about the _running_ configuration. They can
be changed without the process being restarted. Actually environment
variables can fall prey to the same issue if they are simply looked at
once, stuck in a local variable and then that local variable is later
modified, but that isn't as common in my experience.
> If you have ideas about what should (and should not) be done wrt
> canonizing a config file for Zope, please detail specifics here as
> nothing is set in stone.
I suppose, as movement in this direction is imminent, what I can
probably get away with doing is just hooking all my custom environment
variable stuff into the configuration machinery at startup. But thats
assuming that once the configuration file is parsed the results are
bundled into a single data structure that is then globally available to
the rest of the zope machinery. As I haven't looked at the cvs branch
in question perhaps you could tell me how valid this assumption is.
Jamie Heilman http://audible.transient.net/~jamie/
"You came all this way, without saying squat, and now you're trying
to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
I liked you better when you weren't saying squat kid." -Buddy
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -