jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: checkins to jcr-server
Date Fri, 09 Dec 2005 16:03:17 GMT
Angela Schreiber wrote:

> perhabs we have a little disagreement about the aim of
> the webdav implementations present in the jcr-contrib.

probably :)

i'm attempting to use the "simple impl" as a framework for a 
full class 1 and 2 webdav server with all headers, 
properties, etc defined in rfc 2518.

i know that you're not aiming quite that high, but still, we 
should be able to meet both of our goals with the same codebase.

> the implementations of the webdav-library present in the 'server'
> project are not meant to be 'abstract concrete implementations'.
> there are 2 separate, concrete implementations of the library
> interfaces, each for a specific aim: the 'simple-server' and the 
> 'remoting-server'.
> that's why you find 2 implementions of the DavResource interface,
> its factory etc. i tried to design the interfaces in a way that
> its suitable for any kind of implementations, not only the those
> that are available as open-source code.
> if the implemenation you are using for your Cosmo project (which
> also uses CalDAV if i'm not mistaken), needs all the private
> stuff of the simple/DavResourceImpl a little different, then
> it would maybe wise reconsidering the class inheritance.
> is there something specific the library (thus the interfaces
> are missing), that forces you to subclass a specific implementation
> that obviously does not meant your needs?

"obviously does not meet your needs" dramatically overstates 
the problem. let me show you in detail:


CosmoDavResourceImpl subclasses DavResourceImpl. you can see 
that i'm only overriding two of the methods defined by 
DavResource and implemented by DavResourceImpl, in order to 
add caldav-specific info to the compliance class and list of 
supported methods.

however, i also have to override initProperties in order to 
initialize the resource's caldav properties. this is an 
example of a jcr-server method that wasn't designed with 
subclassing in mind. i have to keep my own state variable in 
order to keep this method from running more than once, just 
like the DavResourceImpl's initProperties method.

the fact is, DavResourceImpl is almost perfectly usable for 
me (it was less so in the past, but it's much better now 
after the latest refactoring). there's absolutely no way i 
want to go writing my own implementations of all of the 
jcr-server interfaces, because what's there is good enough 
for me nearly all of the time. if we keep extensibility as a 
primary goal for the simple server, then i'll be able to 
reuse your fine work instead of having to copy it and 
tweaking little bits here and there.

> so, the reason would probably be, that i think the 'simple'
> server is a concrete implemenation and not an abstract one.

i don't see how that justifies keeping some of 
DavResourceImpl's methods private, unless you are 
specifically trying to discourage their use by subclasses 
for some reason, or even trying to discourage subclassing 
altogether. if so, we need to talk more about that specifically.

View raw message