You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Brian Moseley <bc...@osafoundation.org> on 2005/03/08 19:20:47 UTC
WebDAV/CalDAV and remote content stores
what is Jackrabbit's strategy for WebDAV support? are you
providing a stripped-down implementation specifically as a
mechanism for remote access between JCR clients and a
Jackrabbit content store, or do you intend to build a
full-featured WebDAV adapter on top of a content store, or
both (or neither)?
my project is a calendar sharing server that offers
full-featured CalDAV access and a web-based
calendaring/scheduling UI. my initial explorations have been
with Slide, but i find that for several reasons i'd rather
look elsewhere, not the least of which are 1) the lack of a
simple content store API, which is what piqued my interest
in JSR 170, and 2) the need to support a remote content
store deployment. IoC-style configuration and layer
separation also rank high on my list of wants, and the Acegi
WebDAV project seems poised to begin working with Jackrabbit
in that regard.
(1) CalDAV
CalDAV, as you may or may not know, is an extension of
WebDAV that provides a content model for calendar data and
defines calendar access mechanisms. my original plan had
been to help contribute CalDAV support to Slide, but it may
well be a much better choice to contribute that effort to
Jackrabbit instead. of course, that would depend on
Jackrabbit's WebDAV support being fully featured enough to
support CalDAV (for instance, implementing WebDAV ACL).
for those of you who are curious, the current version of the
CalDAV draft is at
<http://ietf.webdav.org/caldav/draft-dusseault-caldav.txt>.
the list of CalDAV requirements includes:
o MUST support WebDAV Class 1.
o MUST support WebDAV ACL with the privileges defined
in Section 7.1 of this document.
o MUST support SSL.
o MUST support strong ETags to support disconnected
operations.
o MUST support all required calendaring REPORTs defined
in this document.
o MUST advertise calendaring REPORTs via the
DAV:supported-report-set property as defined in DeltaV.
and options include:
o SHOULD support MKCALENDAR.
o MAY support WebDAV Class 2 (i.e., locking).
o MAY support WebDAV DeltaV [5] or some of its components.
what would need to happen with Jackrabbit in order to pave
the way for adding full CalDAV support? with such a roadmap,
i may well be able to convince my employer (OSAF) to throw
some support behind this effort.
(2) remote content store/scalability thoughts
i'm also curious what alternative methods you've implemented
and/or envisioned for remote content store access. i saw
mention in the list archives of RMI, though at least one
person expressed a worry at the performance of such. have
any other mechanisms been proposed, or is WebDAV the one
that people like the most?
has any thought been given to
clustering/replicating/distributing/otherwise horizontally
scaling content stores? i could easily build a massively
hosted web calendar UI using traditional clustering
techniques and my own custom content store API on top of an
RDBMS, but i'd like to leverage JCR as much as possible.
there is of course a school of thought that many small
content stores with a locator service like DNS that
identifies the individual store holding a specific piece of
content is a more scalable architecture than one uber
content store. presumably today's Jackrabbit design would
suffice for this architecture, assuming such a locator
service was provided. am i correct in this assumption?
Re: WebDAV/CalDAV and remote content stores
Posted by Stéphane Croisier <sc...@jahia.com>.
At 19:20 08/03/2005, you wrote:
>my project is a calendar sharing server that offers full-featured CalDAV
>access and a web-based calendaring/scheduling UI.
Quite nice! We were thinking about the same idea. We already developed some
JSR168 compliant views on top of UWCAL (http://www.washington.edu/ucal/)
and integrated it with Sync4J (www.sync4j.org). Next step would be to
migrate UWCal to Jackrabbit (in order to have all your events, addresses,
to-do,...) "mounted" in a shared content repository.... Some docs here:
http://cvspub.jahia.org/cgi-bin/cvsweb.cgi/uwcal_JSR168/docs/
So already perhaps a part of your calendar sharing server ;-)... Everything
available under a BSD license (excepted for the Sync4j part but which was
mapped as an optional module to (try to) avoid the viral effect of the GPL).
Cheers,
Stéphane
- -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
www.jahia.org : A Collaborative Source CMS and Portal Server
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
David Nuescheler wrote:
> well, actually i would not store the iCalendar body as a data property,
> but "simulate" an iCalendar file serialization in the webdav layer.
> once somebody PUTs any iCalendar file i would automatically
> deserialize it into the iCalendar properties.
> does that make sense?
yep, it does. that strategy will support CalDAV iff the properties can
reliably be reconstituted into the exact same iCalendar body every time
it is requested.
> cool, do you have already have an idea about the
> structure of the iCalendar nodetype(s)?
not yet - i'm still working on integrating Jackrabbit and jcr-server
with a security framework (Acegi Security) and establishing a web ui for
managing users and access control. when that's working, i'll be ready to
start looking at what needs to be done for CalDAV support.
Re: WebDAV/CalDAV and remote content stores
Posted by David Nuescheler <da...@gmail.com>.
> > personally i would be very interested in porting some of
> > the datamodel behind calendaring to nodetypes.
> > like the vcalendar, vevent and so forth.
> what are your specific thoughts in this regard? do you
> imagine "promoting" iCalendar properties to node properties
> and storing the iCalendar body as a data property? if so,
> what would happen when somebody uses WebDAV to change one of
> these properties? would you rebuild the iCalendar body using
> the new value?
well, actually i would not store the iCalendar body as a data property,
but "simulate" an iCalendar file serialization in the webdav layer.
once somebody PUTs any iCalendar file i would automatically
deserialize it into the iCalendar properties.
does that make sense?
> > i think this
> > would be very helpful to get calendaring interoperable.
> > i believe that storing calendar information in a
> > content repository is the right way to go.
> > serialization/deserialization to and from icalendar and
> > icalendar-xml should be straight forward.
> > i think the above should be undoubted.
> i don't doubt it ;)
thought so ;)
> > once that is done we will have a generic way to
> > bi-directionally access calendaring information
> > through webdav.
> > if someone feels compelled to then implement
> > MKCALENDAR and the rest of CalDAV i think it
> > should not be a lot of effort.
> that is the approach that i have been homing in on, yes.
cool, do you have already have an idea about the
structure of the iCalendar nodetype(s)?
regards,
david
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
David Nuescheler wrote:
> personally i would be very interested in porting some of
> the datamodel behind calendaring to nodetypes.
> like the vcalendar, vevent and so forth.
what are your specific thoughts in this regard? do you
imagine "promoting" iCalendar properties to node properties
and storing the iCalendar body as a data property? if so,
what would happen when somebody uses WebDAV to change one of
these properties? would you rebuild the iCalendar body using
the new value?
> i think this
> would be very helpful to get calendaring interoperable.
> i believe that storing calendar information in a
> content repository is the right way to go.
> serialization/deserialization to and from icalendar and
> icalendar-xml should be straight forward.
> i think the above should be undoubted.
i don't doubt it ;)
> once that is done we will have a generic way to
> bi-directionally access calendaring information
> through webdav.
> if someone feels compelled to then implement
> MKCALENDAR and the rest of CalDAV i think it
> should not be a lot of effort.
that is the approach that i have been homing in on, yes.
Re: WebDAV/CalDAV and remote content stores
Posted by David Nuescheler <da...@gmail.com>.
> there is definite value in coming up with some kind of
> calendaring standard, or else we will never have calendaring
> interoperability, which is completely ridiculous.
agreed.
personally i would be very interested in porting some of
the datamodel behind calendaring to nodetypes.
like the vcalendar, vevent and so forth.
i think this
would be very helpful to get calendaring interoperable.
i believe that storing calendar information in a
content repository is the right way to go.
serialization/deserialization to and from icalendar and
icalendar-xml should be straight forward.
i think the above should be undoubted.
once that is done we will have a generic way to
bi-directionally access calendaring information
through webdav.
if someone feels compelled to then implement
MKCALENDAR and the rest of CalDAV i think it
should not be a lot of effort.
regards,
david
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
Stefano Mazzocchi wrote:
> But then again, using a PUT with a special mime-type for the payload
> maybe wasn't enough for one to name it 'a protocol', have an RFC and
> your name on it.
oh, come on. there is no need for that kind of remark.
there is definite value in coming up with some kind of
calendaring standard, or else we will never have calendaring
interoperability, which is completely ridiculous.
it's perfectly valid if you want to debate the standard. but
if you are just going to sit in the corner and hurl poop at
people trying to get some work done then, you know, no thanks.
Re: WebDAV/CalDAV and remote content stores
Posted by Stefano Mazzocchi <st...@apache.org>.
Roy T.Fielding wrote:
> On Mar 8, 2005, at 10:20 AM, Brian Moseley wrote:
>
>> what would need to happen with Jackrabbit in order to pave the way for
>> adding full CalDAV support?
>
>
> My dead body, most likely, since CalDAV is the worst perversion of
> HTTP that I have seen so far. I will veto its addition to mod_dav
> and jackrabbit. HTTP is supposed to be independent of the content
> being exchanged -- every new content type does not need an entirely
> new application protocol.
Oh man, nothing like a good protocol shakedown to excite the evening :-)
For the record, I'm on Roy side as well: whomever came up with
MKCALENDAR show write on the blackboard "I will read again the HTTP
protocol" a hundred times (a-la Burt Simpson).
But then again, using a PUT with a special mime-type for the payload
maybe wasn't enough for one to name it 'a protocol', have an RFC and
your name on it.
ah, gotta love politics. especially when people claim to have objective
arguments for subjective matter ;-)
--
Stefano.
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
Roy T. Fielding wrote:
> No, just use normal HTTP methods. PUT with a calendar media type
> creates a collection by that name with a default representation
> of the calendar, containing links for adding new entries (POST)
> and identifying existing entries (which can be obtained via GET
> and changed via PUT and DELETE). There is no need for resource-
> specific additions like MKCALENDAR and OPTIONS. Everything that
> needs to be communicated can be described directly within the
> calendar media type rather than in HTTP protocol changes.
i tend to agree with you, though i'm sure the CalDAV authors have a
rebuttal that i haven't considered ;) anyway, this is getting offtopic
for jackrabbit; maybe it will continue on ietf-caldav, maybe not. thanks
for the input tho. i'm pretty excited to actually check out jackrabbit
and give it a whirl.
Re: WebDAV/CalDAV and remote content stores
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 8, 2005, at 1:04 PM, Brian Moseley wrote:
> i wonder the alternative for a calendar protocol based on HTTP is for
> a MKCALENDAR method - SOAP?
No, just use normal HTTP methods. PUT with a calendar media type
creates a collection by that name with a default representation
of the calendar, containing links for adding new entries (POST)
and identifying existing entries (which can be obtained via GET
and changed via PUT and DELETE). There is no need for resource-
specific additions like MKCALENDAR and OPTIONS. Everything that
needs to be communicated can be described directly within the
calendar media type rather than in HTTP protocol changes.
....Roy
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
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.
Re: WebDAV/CalDAV and remote content stores
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
Roy T. Fielding wrote:
> My dead body, most likely, since CalDAV is the worst perversion of
> HTTP that I have seen so far. I will veto its addition to mod_dav
> and jackrabbit. HTTP is supposed to be independent of the content
> being exchanged -- every new content type does not need an entirely
> new application protocol.
heh! i haven't noticed you say so on the ietf-caldav list lately, tho i
haven't read the archives either :)
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).
Re: WebDAV/CalDAV and remote content stores
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 8, 2005, at 10:20 AM, Brian Moseley wrote:
> what would need to happen with Jackrabbit in order to pave the way for
> adding full CalDAV support?
My dead body, most likely, since CalDAV is the worst perversion of
HTTP that I have seen so far. I will veto its addition to mod_dav
and jackrabbit. HTTP is supposed to be independent of the content
being exchanged -- every new content type does not need an entirely
new application protocol.
....Roy
Re: WebDAV/CalDAV and remote content stores
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> both. along with the JCRWebdavServer part comes a very simple WebDAV
> servlet, that exposes the repository in a file-system like way.
> meaning, nt:file is mapped to a non-collection-resource, everything
> else mapped to a collection. most of the webdav operations should
> work. the JCRWebdavServer will also support DeltaV methods for
> versioning.
sounds cool. all there any WebDAV parts that you are specifically
planning to ignore or that you feel will be especially troublesome? if
so, why?
> i suggest you take a look at the stuff that is already contributed.
> you are probably the better person to judge what else is needed.
> further you need probably decide, if the calendar data is stored in a
> unstructured way, defined by the cal application, or if CalDAV needs a
> predefined nodetype set for this.
CalDAV will most likely need to define new node types. beyond that, i
can't say for sure, as i have to refamiliarize myself with the draft and
do some more investigation of JCR.
my biggest area of concern is the CalDAV requirement for WebDAV ACL
support, since it doesn't seem to map very well to JCR, which appears to
have a more restricted privilege set and no mechanism for extending
privileges. any thoughts there?
> not yet. please keep in mind, that jackrabbit is a reference
> implementation. the primary goal is to make it working according to
> the spec.
of course. i'm not going to need clustering anytime soon (or ever,
maybe). i just want to know if anything inherent to jackrabbit's design
would prevent that feature from being added down the road. that doesn't
seem to be the case, but i'm not intimate with the project yet.
thanks for your comments!
Re: WebDAV/CalDAV and remote content stores
Posted by Tobias Strasser <to...@gmail.com>.
hi brian,
> what is Jackrabbit's strategy for WebDAV support?
we are currently working on a WebDAV based jcr client/server protocol.
It uses the standard webdav protocol elements with a few extensions
and some extended semantics on locks. we also integrated microsofts
observation model (subscribe/poll). the idea is to have a
jsr170-to-jsr170 WebDAV layer that is not strictly tied to jackrabbit.
The jackrabbit dependant part of the server is minimal.
we recently contributed the server part of it while still working on
the client. you can find it here:
http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk/contrib/jcr-server
you can find a documentation draft of the protocol here:
http://www.day.com/jsr170/server/JCR_Webdav_Protocol.zip
> are you
> providing a stripped-down implementation specifically as a
> mechanism for remote access between JCR clients and a
> Jackrabbit content store, or do you intend to build a
> full-featured WebDAV adapter on top of a content store, or
> both (or neither)?
both. along with the JCRWebdavServer part comes a very simple WebDAV
servlet, that exposes the repository in a file-system like way.
meaning, nt:file is mapped to a non-collection-resource, everything
else mapped to a collection. most of the webdav operations should
work. the JCRWebdavServer will also support DeltaV methods for
versioning.
> [...]
> what would need to happen with Jackrabbit in order to pave
> the way for adding full CalDAV support? with such a roadmap,
> i may well be able to convince my employer (OSAF) to throw
> some support behind this effort.
i suggest you take a look at the stuff that is already contributed.
you are probably the better person to judge what else is needed.
further you need probably decide, if the calendar data is stored in a
unstructured way, defined by the cal application, or if CalDAV needs a
predefined nodetype set for this.
> (2) remote content store/scalability thoughts
>
> i'm also curious what alternative methods you've implemented
> and/or envisioned for remote content store access. i saw
> mention in the list archives of RMI, though at least one
> person expressed a worry at the performance of such.
no, currently only RMI is implemented and working.
> any other mechanisms been proposed, or is WebDAV the one
> that people like the most?
afaik, webdav and RMI was the only remoting protocols that were really wanted.
> has any thought been given to
> clustering/replicating/distributing/otherwise horizontally
> scaling content stores? i could easily build a massively
> hosted web calendar UI using traditional clustering
> techniques and my own custom content store API on top of an
> RDBMS, but i'd like to leverage JCR as much as possible.
not yet. please keep in mind, that jackrabbit is a reference
implementation. the primary goal is to make it working according to
the spec.
> there is of course a school of thought that many small
> content stores with a locator service like DNS that
> identifies the individual store holding a specific piece of
> content is a more scalable architecture than one uber
> content store. presumably today's Jackrabbit design would
> suffice for this architecture, assuming such a locator
> service was provided. am i correct in this assumption?
yes. if you know what content you need. with a distributed jcr
repository it is harder to leverage it cool features like integrated
search and observation.
cheers, tobi
--
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---