[Zope3-dev] Re: WebDAV Future

[Michael Kerrin]

Hi Martijn,

On Tuesday 24 April 2007 00:30:47 Martijn Faassen wrote:
> Michael Kerrin wrote:
> [snip]
>
[snip]
>
> 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.
>
Either name works for me so lets go for `zwebdav`.

> >   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).
Thanks, you just saved me from wasting a lot of time as this was original my 
favourite option.

> >   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
This I like, but renaming zwebdavext -> zwebdavapp :-) This allows a clearer 
seperatation between the protocol components and the application components, 
which is what want now that I think about it.

For example zwebdavext.zopefile isn't really an extension but more integration 
code for zwebdav and any application which uses zope.file. Then in the future 
I can hopefully get to work on zwebdav.dasl, zwebdav.acl etc. which are 
extensions to the protocol and hence should belong in zwebdav with more 
coresponding integration modules in zwebdavapp.

> 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. :)

Thanks,
Michael