[Zope3-dev] Re: WebDAV Future

[Martijn Faassen]

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