jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Florey <daniel.flo...@web.de>
Subject Re: Suggestion for split of JCR-Server
Date Sat, 22 Apr 2006 13:38:40 GMT
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 jackrabbit.
In a perfect world I'd like to see a completely separate webdav-project containing all the
apache contributions to webdav. Even though it will never contain the most popular mod_dav
and other projects outside the java world, it would be great to have at least a single place
to host the stuff that has been developed for jackrabbit and Slide that is of general use.
Something like:
  [would contain a webdav library / api reflecting the different webdav rfc's]
  [different interfaces for each rfc like webdav, lock, dasl, deltav, acl, binding etc.]
    [containing server side implementations of the api]
    [contains webdav-servlet to map webdav-requests to api]
    [containing client side implementations of the api]
    [containing a comprehensive set of testcases to check webdav compliance. slide testsuite
could be a good starting point]
    [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 addressed using the same api. For example
the MS Exchange server implements webdav-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, Notifications {
   ... implementing all webdav methods exposed by the interfaces 

We could provide two different impls of the api for jackrabbit, one for client side access
and one for server side access. Once the api is implemented the webdav-servlet can be used
to access jackrabbit using the webdav protocol.
So if someone wants to webdav-enable an existing repository, the vendor just 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 times and many people
might be bored, but if someone would agree, I'd like help to move towards this direction.
Anyway, splitting the webdav stuff into a separate subproject is a good step into the right


> -----Ursprüngliche 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
> 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.
> 1) Proposal for webdav project structure
> ----------------------------------------------------------------
> + 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                ]
> 2) Missing separation of commons and server api
> -----------------------------------------------------------------
> 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.
> however i found, that both 'DavResource' and the
> 'DavServletRequest'/'DavServletResponse' are tied too much
> into common utilities such as DavMethod and MultiStatus etc.
> 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.
> 3) Dependencies from 'jcr' package
> -----------------------------------------------------------------
> the 'simple' currently contains the following dependencies
> to the 'jcr' implementation:
> - JcrDavException:
>    Extension to DavException that translates the various
>    RepositoryExceptions to error-codes.
> - JcrDavSession:
>    Abstract class that wraps javax.jcr.Session and provides
>    access to this repository session.
> - 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.
> - The simple servlet uses the locator factory implementation
>    from the webdav.jcr package.
> 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?). currently the dependencies are
> internal only and a replacement should be possible.
> 4) What represents the 'core' implementation
> ------------------------------------------------------------------
> 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érémi would then act as basis
> for the core. the 'simple' may extend from the 'core' as well
> but not the other way round.
> 5) Why a separate 'server/config'
> ------------------------------------------------------------------
> 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).
> 6) what will be in the 'jcr-server'
> ------------------------------------------------------------------
> in the 'jcr-server' would remain the 'webdav/jcr' package,
> the 'server/jcr' package and the JCRWebdavServerServlet.java.
> what do you think?
> regards
> angela

SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

View raw message