Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <439FEE36.6010009@day.com>
Date: Wed, 14 Dec 2005 11:04:38 +0100
From: Angela Schreiber <anchela@day.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: webdav server(s)
References: <20051207174840.66169.qmail@minotaur.apache.org>
 <43981892.5060906@day.com> <439860D6.9020802@osafoundation.org>
 <439DF75B.9090907@osafoundation.org> <439E8C6A.1090605@day.com>
 <439E9BC8.3000309@osafoundation.org> <439EAB6C.1030009@day.com>
 <439EF8D2.3030405@osafoundation.org> <439F04DD.8040806@day.com>
 <439F16B3.7000308@osafoundation.org>
 <E82E32ED-D346-4C6C-B57B-303B6C314E19@gbiv.com>
In-Reply-To: <E82E32ED-D346-4C6C-B57B-303B6C314E19@gbiv.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

hi roy

thanks for your summary. just let my address two things.
please apologize if this is completely redundant and totally
clear to everybody...
at the end i'd like to list the common parts from my
point of view.

Roy T. Fielding wrote:
> I think I understand now the disjoint thoughts on how the jcr-server
> should be designed.  The existing jcr-server is a webdav view of a
> JCR repository, 

this is correct for the "jcr-server/server" project, which contains
2 separate views to a JSR170 repository:

- simple server ('simple'):
   provide a human readable ('filesystem') view to the jcr-repository.
   one very easy example was to map 'nt:file' to non-collections
   and anything else to collections.

- remoting server ('jcr'):
   using webdav as transport layer for the remoting of the JSR170 api.
   the reason for this was, that - from our point of view -  webdav
   is about 'collections' and their 'members' and not about files
   and folders.

> whereas it seems Brian is looking for a general
> webdav server that happens to use JCR as its storage interface.

that's what we designed the "jcr-server/webdav" (the webdav library)
for. provide all the webdav stuff that is not related to JSR170.
except for 3 methods there is nothing JSR170 related within those
interfaces (and classes).

but yes, there is no general implementation for the DavResource
and related interfaces.

> What I suggest is that we start a separate contrib project for a
> general webdav server implemented using JCR and see how much of
> the code can be shared between the two, gradually merging them
> together until we reach a point where the two are (hopefully)
> distinguishable only by configuration files.  What do you think
> of that as a plan?

thanks. sounds good to me.
i see the following common parts:

- jcr-server/webdav project ('dav library')
- jcr-server/server/[...]/AbstractWebdavServlet
- jcr-server/webapp/ except for 2 subclasses of AbstractWebdavServlet

in addition:

maybe the jcr-server/webapp/[...]/SimpleWebdavServlet could
partially be reused (but maybe brian has some additional stuff).

perhaps i'm missing some fundamental things (blind because
i spent quite some time on the jcr-server contrib). but from
my point of view, it's the general implementation of the
following interfaces that is missing:

- DavResource
- DavResourceFactory
- DavResourceLocator
- DavResourceLocator

plus generic configuration (there is no such thing in the
library) to make the general implementation suitable for all
kind of JSR170 implementations.

> ....Roy

kind regards
angela