You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@codeconsult.ch> on 2002/06/04 10:42:39 UTC
Re: Thoughts about requirements for a cms (WebDAV vs. Slide API)
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.
>
> 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.
> * 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!
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Thoughts about requirements for a cms (WebDAV vs. Slide API)
Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.
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
libary.
> > * 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="http://www.foo.bar/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org