Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 22 Apr 2006 15:38:40 +0200
Message-Id: <200101219@web.de>
MIME-Version: 1.0
From: Daniel Florey <daniel.florey@web.de>
To: dev@jackrabbit.apache.org
Subject: Re: Suggestion for split of JCR-Server
Organization: http://freemail.web.de/
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

Hi,
this is a good idea! I'd like to see a webdav project even more separated =
from jackrabbit as it contains some usefull code that is not tied to jackr=
abbit.
In a perfect world I'd like to see a completely separate webdav-project co=
ntaining all the apache contributions to webdav. Even though it will never=
 contain the most popular mod=5Fdav and other projects outside the java worl=
d, it would be great to have at least a single place to host the stuff tha=
t has been developed for jackrabbit and Slide that is of general use.
Something like:
+webdav
  +api
  [would contain a webdav library / api reflecting the different webdav rf=
c's]
  [different interfaces for each rfc like webdav, lock, dasl, deltav, acl,=
 binding etc.]
  +server
    [containing server side implementations of the api]
    +common
    [contains webdav-servlet to map webdav-requests to api]
    +jackrabbit
    +slide
  +client
    [containing client side implementations of the api]
    +common
    +jackrabbit
    +slide
    +exchange
    +subversion...
  +testsuite
    [containing a comprehensive set of testcases to check webdav complianc=
e. slide testsuite could be a good starting point]
  +webapp
    [should use webdav-api to work with all server side impls]

The basic idea behind this approach is to have a flexible webdav api that =
enables us to access different servers with different features to be addre=
ssed using the same api. For example the MS Exchange server implements web=
dav-based locking, dasl, transaction-handling, and notifications.
In this case we would implement a client side impl of the api somehow like=
 this:

class ExchangeRepository implements Locking, ACL, DASL, Transactions, Noti=
fications {
   ... implementing all webdav methods exposed by the interfaces=20
}

We could provide two different impls of the api for jackrabbit, one for cl=
ient side access and one for server side access. Once the api is implement=
ed the webdav-servlet can be used to access jackrabbit using the webdav pr=
otocol.
So if someone wants to webdav-enable an existing repository, the vendor ju=
st needs to implement the api interfaces he supports and can use the given=
 infrastructure without the need to parse request and construct responses.=

Ok, I'll stop at this point as I tried to propose this approach several ti=
mes and many people might be bored, but if someone would agree, I'd like h=
elp to move towards this direction.
Anyway, splitting the webdav stuff into a separate subproject is a good st=
ep into the right direction!!

Cheers,
Daniel


> -----Urspr=FCngliche Nachricht-----
> Von: dev@jackrabbit.apache.org
> Gesendet: 20.04.06 08:29:47
> An: dev@jackrabbit.apache.org
> Betreff: Suggestion for split of JCR-Server


> hi
>=20
> as mentioned and discussed several times before, we may
> think about splitting the 'jcr-server' project into
> a webdav specific project and the jcr-server.
>=20
>=20
> 1) Proposal for webdav project structure
> ----------------------------------------------------------------
>=20
> + jackrabbit
>    + webdav
>      + commons
>          [ would contain the current webdav library including ]
>          [ its dependency to servlet api (see 2)              ]
>          [ no dependency to jsr170 api nor jackrabbit         ]
>      + server
>        + config (see 5)
>        + io
>        + "simple-server-implementation"
>        + "core-server-implementation" (see 4)
>      + client
>          [ the dav extension of httpclient methods            ]
>          [ further dav-client development                     ]
>      + webapp
>          [ repository-access-servlet, dav-servlets            ]
>          [ only here: dependency to jackrabbit                ]
>=20
>=20
> 2) Missing separation of commons and server api
> -----------------------------------------------------------------
>=20
> i tried to move everything with dependency to the servlet api
> and all the 'resource' interfaces to the 'server' and reduce
> the 'commons' to classes/interfaces which are shared between
> server and client.
>=20
> however i found, that both 'DavResource' and the
> 'DavServletRequest'/'DavServletResponse' are tied too much
> into common utilities such as DavMethod and MultiStatus etc.
>=20
> thus, moving those server specific interfaces out of the
> common library would lead to substancial redesign which
> i would prefer not to mix with that initial split. instead
> this should go into the todos for a major release.
>=20
>=20
> 3) Dependencies from 'jcr' package
> -----------------------------------------------------------------
>=20
> the 'simple' currently contains the following dependencies
> to the 'jcr' implementation:
>=20
> - JcrDavException:
>    Extension to DavException that translates the various
>    RepositoryExceptions to error-codes.
>=20
> - JcrDavSession:
>    Abstract class that wraps javax.jcr.Session and provides
>    access to this repository session.
>=20
> - JcrActiveLock:
>    Wraps a javax.jcr.Lock object. This class has a dependency
>    to the ItemResourceConstants (destinction of session scoped
>    locks) which is useful for the jcr-server only, not for
>    'simple' or some generic server.
>=20
> - The simple servlet uses the locator factory implementation
>    from the webdav.jcr package.
>=20
> I think that all of the mentioned classes in fact represent
> a common basis for dav implementations on top of jsr170
> compliant repository and should rather be part of a util
> package (or of the core=3F). currently the dependencies are
> internal only and a replacement should be possible.
>=20
>=20
> 4) What represents the 'core' implementation
> ------------------------------------------------------------------
>=20
> i would suggest to use the 'core' as base implementation for
> dav-server on top of a jsr170 compliant repository. the
> extensions provided by j=E9r=E9mi would then act as basis
> for the core. the 'simple' may extend from the 'core' as well
> but not the other way round.
>=20
>=20
> 5) Why a separate 'server/config'
> ------------------------------------------------------------------
>=20
> currently only the 'simple' server provides a simple and limited
> configuration. in order to be able to create a configuration
> suited for a broader usage and for a general server i would
> suggest to start with a separat config package.
> the 'simple' package would contain the original config classes
> for backwards compatibility (but marked deprecated).
>=20
>=20
> 6) what will be in the 'jcr-server'
> ------------------------------------------------------------------
>=20
> in the 'jcr-server' would remain the 'webdav/jcr' package,
> the 'server/jcr' package and the JCRWebdavServerServlet.java.
>=20
>=20
> what do you think=3F
>=20
> regards
> angela
>=20


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/=3Fmc=3D021192