[Cosmo-dev] Cosmo Jackrabbit nodes

Brian Moseley bcm at osafoundation.org
Fri Jun 30 16:30:42 PDT 2006

On 6/29/06, Vinubalaji Gopal <vinu at osafoundation.org> wrote:

>   I was able to dump the complete repository (the Jackrabbit tree) using
> a dump utility (custom function) and see the entire repository created
> by Cosmo. I have put my dump file and the explanation at:
> http://wiki.osafoundation.org/bin/view/Projects/CosmoJackrabbit

neat :)

> I believe that the ics files are parsed using the ical4j library and the
> properties of the ics file are stored as jackrabbit properties (like
> icalendar:vcalendar-vevent_description, etc) and as complete ics files
> (part of jcr:content node).

correct. we store the original icalendar object so that we can return
it for GET requests exactly as it was provided (so that strong etags
can be used). we also store jcr properties for most of the icalendar
entities contained with the object in order to efficiently service
report queries.

note that some (most?) of the time, reports only actually return some
of the components/properties/parameters of the icalendar object. this
implies that we could potentially construct report responses directly
from the jcr properties rather than by parsing the calendar object and
finding within it the entities required for the report response. this
might save some processing and storage, but it means that we can't
guarantee byte-for-byte equality with the originally submitted
resource, and i think that's more important. we can achieve better
performance by caching the parsed icalendar objects in memory when we
save them into the repository.

> There are two projects (AFAIK) that implements the vCard RFC and that
> could be used for parsing.
> http://sourceforge.net/projects/vcard4j/
> http://sourceforge.net/projects/mime-dir-j/
> Both are licensed under LGPL. Suggestions about the API (including links
> to other projects if any) are welcome. I am inclined towards mime-dir-j
> because its labeled stable in sourceforge and source code looks neater.
> I really doubt if vcard4j has any relation to ical4j, but would like to
> know if its related and if so how good is the ical4j code.

i like vcard4j's api (net.sf.vcard4j.java and friends) except for its
tight coupling with the dom api and the fact that it hasn't been
maintained in a long time. i don't see that mime-dir-j adds anything
particularly useful except that it fixes some bugs in vcard4j. the
majority of our usage will be parsing vcards out of text streams, not
programatically constructing them, so i don't think mime-dir-j's
interfaces would be useful.

it's very possible that we could extend ical4j to handle vcard. the
underlying text formats are very similar. however, for practicality's
sake, we might want to get started with vcard4j to get some working
code in place and then look at what it might take to replace that api
with a better, more efficient one. let's not prematurely optimize -
there are probably worse bottlenecks than building a dom to represent
a vcard :)

> Apart from that I would also like to start a discussion on the
> repository hierarchy in cosmo and the changes I will make to support
> CardDAV.
> After going through the code I realized that most of the properties are
> set using setProperty (which creates a property if the property does not
> exist) since some of the properties of a ical may be optional. I would
> like to add vcard properties in a similar fashion.

do you mean javax.jcr.Node.setProperty? which cosmo code are you referencing?

> I would like to know the importance of this two properties, part of a
> calendar collection, is it defined by the spec or defined by Cosmo? :
> calendar:language = en_AU
> calendar:supportedComponentSet = VEVENT

a calendar's language specifies the human language used to communicate
the calendar's description. these two pieces of data are stored as the
calendar:language and calendar:description jcr properties and are
available to caldav clients as the CALDAV:calendar-description dav
property with the xml:lang attribute.

the supported component set for a calendar specifies the calendar
component types (eg VEVENT, VTODO, VJOURNAL, VFREEBUSY) that can be
stored inside the calendar. this is available to caldav clients as the
CALDAV:supported-calendar-component-set dav property.

> I did not see any timezone (calendar:timezone) property set by Scooby,
> but I am equally curious about this property?

a calendar's timezone is used to resolve floating dates within the
calendar's members. see the CALDAV:timezone dav property.

in general, you want to refer to section 5.2 of the caldav spec for
the definitions of calendar collection properties. note that we don't
yet support several of the properties specified in drafts 10 and

> What is the purpose of copy attribute of a property in jackrabbit? I
> could not find much details about this attribute in the jackrabbit
> documentation.

this is tthe on-version attribute of the property type. this defines
what happens to the property value when its parent node is versioned.
it's not really relevant for us, since we don't support versioning,
and in fact our use of 'copy' in our cnd is redundant since it's the
default value for this attribute.

More information about the cosmo-dev mailing list