Hi Jim

Betreff: [Zope-dev] Optional integration need not introduce dependencies

In discussing dependencies, as we try to clean up dependencies of Zope (especially ZTK) projects, I've noticed a pattern that I think deserves some special handling.

Often, a module (including a ZCML file) within a project provides an implementation of an interface defined by an external package or an adapter of a class or interface defined in the external package. If the module is optional and exists solely to integrate with the external API, then the external project need not be a dependency. Why? Because an application won't use this module unless it already uses the external project.

For example, lots of projects provide publisher views or zcml configuration directives. As long as these are in optional modules or ZCML files, then dependencies on zope.publisher or zope.configuration aren't necessary, as no one will use these modules or zcml files unless they're already using zope.publisher or zope.configuration. Again, this assumes that these modules are optional. For example, if a project's configuration file, configure.zcml registers views or includes a configuration file that registers views, then the dependency on zope.publisher is not optional.

Let's look at a more specific example. zope.app.publisher provides some xmlrpc view registrations for zope.container in xmlrpc/configure.zcml. If the xmlrpc module was optional, or if these container registrations were conditedl [1]_ on zope.container having been installed, then zope.app.publisher wouldn't need to depend on zope.container [2]_. As it stands though, one can't include the main configuration for zope.app.publisher without also configuring the container xmlrpc views, so zope.container is required.

Jim

.. [1] We can make these registrations conditional on zope.container like this:

<configure condition="installed zope.container" > <view for="zope.container.interfaces.IItemContainer" type="zope.publisher.interfaces.xmlrpc.IXMLRPCRequest" provides="zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher" factory="zope.container.traversal.ItemTraverser" permission="zope.Public" /> <view for="zope.container.interfaces.IReadContainer" type="zope.publisher.interfaces.xmlrpc.IXMLRPCRequest" provides="zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher" factory="zope.container.traversal.ContainerTraverser" permission="zope.Public" /> </configure>

.. [2] This assumes we could get rid of the zope.container import in browser/tests/test_directoryresource, which I strongly suspect we can.)

I think XML-RPC just belongs to an own package e.g. zope.xmlrpc. It doesn't make sense to have XML-RPC in a package other then an own. If we move the XML-RPC part out of other packages, then we have the question should the zope.xmlrpc package depend on IContainer? Probably not and the new zope.xmlrpc package should use your suggested conditional configuration. Such an own zope.xmlrpc package whould depend on the publisher as much as the XML-RPC implementation does. This allows to use a custom XML-RPC implementation based on something else then the publisher concept. (custom xmlrpc package) Does this make sense? btw, I think XML-RPC should be an optional package like z3c.jsonrpc. The same belongs to FTP and WebDav support. (Not sure if WebDav is optional, at least FTP is optional configurable at zope.conf level) Regards Roger Ineichen

-- Jim Fulton _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )