Hi Jim. What does this mean? Will the new package be a drop in replacement for what we have without some direction on what to do with the other bit or will it break our applications. A working publisher is pretty essential to a functioning zope app. Does this mean the end of deprecation warnings for the publisher? Is this not useful? Many thanks. Regards, David Jim Fulton wrote:
I'd like reduce the barrier of entry for using the Zope 3 zope publisher. Right now, it has quite a few dependencies setuptools, zope.component, zope.event, zope.exceptions, zope.i18n, zope.interface, zope.location, zope.proxy, zope.security, zope.deprecation, and zope.deferredimport. This seems a bit extreme. I can get rid of zope.deprecation and zope.deferredimport directly. I'd like to get rid of more.
I'm thinking of creating a separate package that contains much of the guts of zope.publisher, but without most or all of the existing dependencies. I'd then modify zope.publisher to import code from this other package, adding the bits that exist now that cause the dependencies.
This new package would a number of things, including skin support, xmlrpc support, mapply, interface declarations and various view base classes that now live in zope.publisher.
Thoughts? Objections?
Jim
-- Jim Fulton Zope Corporation
_______________________________________________ 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 )