Roy T. Fielding wrote:
We might as well be using a proprietary protocol between client and server, since the client is dictating the server implementation.
is it, though? Jackrabbit and Slide are two examples of servers that successfully map WebDAV to relational database backends, right? so even if it looks like a file to a WebDAV client, the server isn't forced to implement it as a file. or is that not what you're talking about?
i wonder the alternative for a calendar protocol based on HTTP is for a MKCALENDAR method - SOAP?
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.
that might be challenging, giving that my boss is the lead on the CalDAV spec ;)
if i was just doing a web ui, i would absolutely stick to stock JCR/jackrabbit. but i have to be interoperable with CalDAV clients as well. so one way or the other i'm going to be extending somebody's WebDAV implementation. for jackrabbit, sounds like that extension includes defining new node types and maybe more content model specific work. we'll see. at this point i'm still trying to convince the people around me that moving away from Slide is a good idea.
