cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject Re: Thoughts about requirements for a cms (WebDAV vs. Slide API)
Date Tue, 04 Jun 2002 09:14:18 GMT

On Tue, 4 Jun 2002, Bertrand Delacretaz wrote:

> On Tuesday 04 June 2002 10:18, Stephan Michels wrote:
> >. . .
> > Pro's :
> >  * you will be indepedent from the  back-end.
> In theory yes.
> But running the backend in a separate process is also very important IMHO.
> You won't get JAR or JDK version conflicts with slide or whatever WebDAV
> backend you're using. Makes the whole thing easier to test too.

Yes, totally agree.

> >
> > Contra's :
> >  * More overhead, so it will be slower
> That's the price to pay for modularity and thin interfaces.
> In my book it's worth it 99% of the time.
> >  * Worry about if you have all possibilities as from a direct access, e.g.
> >    revision control.
> WebDAV provides DeltaV for this, but I don't know if Slide implements it
> already. If not, it's always possible to abstract the revision stuff so that
> it can use DeltaV when available. Same for DASL if it's not available in
> Slide today

After a look into the org.apache.webdav.* from Slide, I think pretty
clean. They have revision control and search support in the webdav client

> >  * Easier to implement
> And learning to program WebDAV is more "reusable" knowledge than learning the
> Slide API I think.
> So I'm all for a WebDAV interface to content stores!

Okay okay, I think also. The good thing you could separate the WebDAV
Server another maschine, that really an argument.

So we need something like dav://<uri>?principal=<name>&password=<bla>

Ps. I hate the namespace 'DAV:', but anyway... ;-)

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
 <D:prop xmlns:R="">

To unsubscribe, e-mail:
For additional commands, email:

View raw message