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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
