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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )