Hi Fred, Fred L. Drake, Jr. wrote at 2003-12-30 15:08 -0500:
... Dieter Maurer writes:
... I feel the configuration process is not yet as modular as it should be?
There's certainly room for improvement.
Let's explain what extensions I have:
1. an alternate "Transience" implementation for Zope sessions
I don't know how the session machinery works in Zope; if there's a section to configure that at all, it should at least be easy to make it possible to provide an alternate section type that can be used.
It uses top level keys for configuration. But anyway (even if session configuration were encapsulated in its own section), I would need to change the Zope schema (if I understand "ZConfig" correctly, which is not yet sure). Ideally, I would like to be able to combine schemas from schema components -- say: "use the standard Zope schema and apply the following additions/changes".
What changes did you need to make to Zope to make this configurable?
I added a "session_module" key to "zopeschema.xml".
2. a new log handler "rotated_logfile" (which performs automatic daily rotation with log files named "prefix.date")
This doesn't need any changes in zLOG; you should be able to provide a new component and use %import to load it in the configuration.
Thank you for confirmation. I expected this to be so.
3. a common piece of configuration used for communication between Zope and a "checkZope" process (which supervises that Zope responds sufficiently fast)
I solved 1 and 2 by rudely modifying Zope sources ("zLOG/component.xml" and associated "handlers", "Zope/Startup/zopeschema.xml" and associated "handlers"). I do not yet have a solution for 3 but I probably will give the "checkZope" process the complete Zope schema and configuration file.
I'm not sure why you want the checkZope process to load Zope's configuration at all. Can't you just use a separate configuration file? If there are portions that need to be shared, you can place those in a separate file and %include that into the Zope and checkZope configurations.
Thank you: I overlooked the "%include" for configuration files. It satisfies my use case with respect to the actual configuration. I must still think about it on the schema level (but that is not pressing as the affected schema part is trivial).
...
I think, a general "include" function for schemas (including not only types but complete schemas) and configuration files could provide this kind of modularity.
Have you looked at the <schema extends="..."> support Phillip Eby added?
I read about it but did not recognized its potential to solve my modularity requirements. I do now! Thank you! Thus, all my wishes are already addressed by the current "ZConfig" :-) -- Dieter