Hey,

Michael Kerrin wrote:
[snip]
Now into future. I want to split this up into a core Zope3 WebDAV implementation, which will handle registering the different WebDAV methods, their implementation, declaring properties, exception handing which I could call z3c.webdav. This module / egg on it own will be pretty useless, as it doesn't know about any of the content or services in Zope3. Then I want for each content type and services in Zope its own egg so to speak, for example z3c.webdav.zopeappfolder, z3c.webdav.zopeappfile, z3c.webdav.zopefile, z3c.webdav.zopelocking. A lot of these extra eggs will be small and easy to write, and as more content types are supported by Zope3 I would like more webdav modules to be written for them.


You can almost do this, but now quite, as z3c.webdav is not a namespace package in this plan (see below).

  An other two options I can think of, instead of the naming convention above:

1. create a webdav namespace, webdaz (WebDAv for Zope), which would contain webdaz.core, webdaz.zopefile, webdaz.zopelocking etc

It's nice that it's more flat. I think it's too easy to mistype 'webdaz' for 'webdav', so -1 on this one from me. zwebdav would in fact have my preference if you want to go this way.

2. Name the core webdav implementation z3c.webdav and then create eggs that are named like zope.file.webdav (for zope.file), zope.app.file.webdav, z3c.extfile.webdav, zope.locking.webdav etc. but which are separate from the underlying module.

This won't work, as these packages themselves are not a namespace package. As far as I'm aware, you can only create independently installable eggs for subpackages of namespace packages (i.e. packages without any code).

Does any one have any experience with this type of problem or does any one of a preference to which one they like best. Or is there other options that I have missed that is worth considering, in order for me to move this forward.

Another option is to create a zwebdav or z3c.webdav package, and then put a special namespace package in there meant for the extensions:

zwebdav - core zope 3 webdav support

zwebdav.ext - pure namespace package

zwebdav.ext.zopefile, zwebdav.ext.zopelocking, etc.

ToscaWidgets is an example of a package that does this. It has a toscawidgets core, and then extensions are shipped as subpackages of the toscawidgets.widgets namespace package.

Yet another option would be to have a core package, and then extension package in another namespace altogether:

zwebdav - core webdav support

zwebdavext.zopelocking, zwebdavext.zopefile - extensions

Grok does this. It has 'grok' as the core, and extensions are shipped as 'megrok.five' and so on.

Incidentally, we are thinking about splitting up grok into multiple packages too. A difference with what you're talking about is that the grok package will remain the same, but will start importing some of what it needs from other packages which can be used independently.

For that, we intend to do something like this:

grok - package end users see, and depends on

  groklib (name still being pondered) - core grokker implementation

  grokcore.component - basic component architecture support for grok
  grokcore.formlib - formlib support for grok


etc. The grokcore packages would have dependencies on groklib as well as various Zope 3 packages (such as zope.component). Some of them may also build on each other. groklib wouldn't have any dependencies (or almost none). grok would depend on everything. Not very relevant to your problem, but thought I'd show yet another example of package organization. :)

Regards,

Martijn

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to