jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: checkins to jcr-server
Date Fri, 09 Dec 2005 10:02:53 GMT
hi brian

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

i was thinking about this tonight and maybe i have to
write down some of my fundamental considerations, while
writing the jcr-server.

since this will take longer than just a few minutes,
i'd like to send but a short reply to one thing that i think gets
pretty close to our misunderstanding:

Brian Moseley wrote:
> Jukka Zitting wrote:
>> I'm not so familiar with the jcr-server design that I can comment on 
>> design decisions there, but in general i disagree with the above 
>> principle. :-)
>> A method should be private if there is no specific reason otherwise. A 
>> non-private method is a part of the external API contract of a class 
>> and  carries with it all the burden of API compatibility. The narrower 
>> the API contract of a class is the easier the class is to restructure 
>> to match an evolving environment. A narrower API is also easier to 
>> document and maintain. In general it is much easier to relax the 
>> visibility of a method when needed than to restrict the availability 
>> of a non-private method.

> ok, in general i agree with you, so let me refine the principle: for 
> jcr-server framework classes, especially but not limited to those which 
> are abstract concrete implementations of interfaces, we should favor 
> protected access for methods over private unless it can be shown that a 
> subclass should by design never have any interest in the method.

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 

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?

> angela mentioned that there was a specific reason that she wanted 
> certain CosmoDavResourceImpl methods private. i hope she'll share that 
> reason. 

oh... i always to to share my reasons :)) even if i'm struggling
finding the proper words in english.

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

hope, this solves some of the points.

kind regards

View raw message