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:
<http://svn.osafoundation.org/server/cosmo/branches/0.2/src/main/java/org/osaf/cosmo/dav/impl/CosmoDavResourceImpl.java>
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.
