On Mar 8, 2005, at 12:06 PM, Brian Moseley wrote:
heh! i haven't noticed you say so on the ietf-caldav list lately, tho
i haven't read the archives either :)
It is too far gone to deal with the design misunderstandings on
a mailing list -- I tried that with WebDAV and ultimately failed
because the people involved were too focused on getting a Save As...
dialog working to even recognize the design mistake of requiring
the client assume it is working with files. CalDAV is worse because
it takes a simple application that could be defined as two media
types (one for the calendar and one for the entry) and instead
describe it as new "types" of resources with special resource-specific
operations for manipulating its state. We might as well
be using a proprietary protocol between client and server, since
the client is dictating the server implementation.
i respect and understand this opinion. if jackrabbit isn't the
appropriate place for this work, i can do it elsewhere and layer it on
top of jackrabbit (or another JCR implementation, though i haven't
seen any others that i would consider using).
It should be possible to use node types and java's inheritance to
extend jackrabbit. However, it would also be trivial to create a
better calendar implementation without making any changes to
jackrabbit -- just define the media types.
....Roy
