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
'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?
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
angela
