Today, I incorporated our Zope extensions into Zope 2.7 and had to determine how I can provide the necessary configuration through ZConfig. I feel the configuration process is not yet as modular as it should be? Let's explain what extensions I have: 1. an alternate "Transience" implementation for Zope sessions 2. a new log handler "rotated_logfile" (which performs automatic daily rotation with log files named "prefix.date") 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. Almost surely, it would not have been necessary to modify the "zLOG" configuration to get a "rotated_logfile" because components and sectiontypes provide enough modularity. However, schemas and configuration files seem not to be modular. I would like to compose schemas and configuration files from components: e.g. combine the standard Zope schema and a small schema for our extensions to form the schema used by the extended Zope, combine the configuration file from long living Zope settings (maintained in CVS), instance specific Zope settings (locally maintained) and configuration fragments used by Zope and other components (e.g. the "checkZope" process). I think, a general "include" function for schemas (including not only types but complete schemas) and configuration files could provide this kind of modularity. -- Dieter
Dieter Maurer writes:
Today, I incorporated our Zope extensions into Zope 2.7 and had to determine how I can provide the necessary configuration through ZConfig. 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. What changes did you need to make to Zope to make this configurable?
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.
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.
Almost surely, it would not have been necessary to modify the "zLOG" configuration to get a "rotated_logfile" because components and sectiontypes provide enough modularity.
Yup.
However, schemas and configuration files seem not to be modular.
Not terribly, no. That wasn't a requirement that anyone made me away of at the time. Bits of configuration files can be stored in separate files and composed using %include.
I would like to compose schemas and configuration files from components: e.g. combine the standard Zope schema and a small schema for our extensions to form the schema used by the extended Zope, combine the configuration file from long living Zope settings (maintained in CVS), instance specific Zope settings (locally maintained) and configuration fragments used by Zope and other components (e.g. the "checkZope" process).
One approach we've taken on some projects is to place all settings within sections, leaving the top-level as a place to put the sections. This wasn't done for the main Zope schema due to various forces; perhaps that was a mistake.
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? -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
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
Dieter Maurer writes:
It uses top level keys for configuration.
Sigh. We should change that.
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).
That depends on how we do it. We could easily make an abstract section type (think "interface"), and the current session machinery and your custom machinery could both implement that. Each would define a section type that "implements" that interface, and the resulting configuration object would be a factory for the session manager. (This is how log handlers are done.)
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".
If we used an abstract section type for a session manager, the Zope schema would require the abstract type; loading the additional schema component would be a matter of adding a %import line in the configuration file.
Thus, all my wishes are already addressed by the current "ZConfig" :-)
Glad to hear it! There are probably changes we'll want to make to the shape of the actual Zope configuration (like moving the session management configuration to a section with an abstract type); input like yours is very valuable in this area. Thanks! -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Thu, 2004-01-01 at 22:41, Fred L. Drake, Jr. wrote:
Dieter Maurer writes:
It uses top level keys for configuration.
Sigh. We should change that.
In a perfect world, it would be possible to extend or change the main section of a schema (or any section in a schema) with altnerate keys or sections, I think. I have no idea how to do it, though. - C
Chris McDonough writes:
In a perfect world, it would be possible to extend or change the main section of a schema (or any section in a schema) with altnerate keys or sections, I think. I have no idea how to do it, though.
Phillip Eby and I discussed the override issue a bit, and decided that it wouldn't be too hard to do, but we had no concrete need. Adding keys and sections is easy with Phillip's <schema extends='...'> support. These ideas all revolve around creating new schemas, though, so aren't quite what we've done with Zope itself. We can already create new implementations of abstract types and load them through %import in specific configurations; this only applies to sections, though. I suspect the current support is pretty much what we're looking for; if we're forced to describe things as components in the configuration, we'll be forced to deal with them as components in the implementation. I expect this will lead to better understood implementations, as each piece is more easily understood in isolation, and more readily maintained. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
That sounds fine to me. Note that the hysterical raisin for not componentizing the zope.conf file (by splitting functional parts into sections) was because the very (wayyyy back) original intent was to make it look and act a lot like a Squid config file, which does not have sections. It makes sense now to take a different approach. On Fri, 2004-01-02 at 01:44, Fred L. Drake, Jr. wrote:
Chris McDonough writes:
In a perfect world, it would be possible to extend or change the main section of a schema (or any section in a schema) with altnerate keys or sections, I think. I have no idea how to do it, though.
Phillip Eby and I discussed the override issue a bit, and decided that it wouldn't be too hard to do, but we had no concrete need. Adding keys and sections is easy with Phillip's <schema extends='...'> support. These ideas all revolve around creating new schemas, though, so aren't quite what we've done with Zope itself.
We can already create new implementations of abstract types and load them through %import in specific configurations; this only applies to sections, though.
I suspect the current support is pretty much what we're looking for; if we're forced to describe things as components in the configuration, we'll be forced to deal with them as components in the implementation. I expect this will lead to better understood implementations, as each piece is more easily understood in isolation, and more readily maintained.
-Fred
participants (3)
-
Chris McDonough -
Dieter Maurer -
Fred L. Drake, Jr.