[Cosmo-dev] Cosmo Jackrabbit nodes

[Brian Moseley]

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

> Regarding extending iCal4j to support vCard parsing, I feel that:
> 1. upgrading the original package(ical4j) may be a pain in case there
> are lot of changes.

we've already made extensive changes to ical4j in our svn repository.
yea, it can be tough to merge our local changes when upgrading to new
versions of the external library, but we try our best to minimize the
effort.

> 2. I really doubt if anything of iCal parsing will be useful, since the
> vCard elements are completely different.

but the underlying name:value format is the same, with semicolon
delimited parameters and line folding and so forth. we'd probably have
to provide our own vcard "type" classes (which are similar to ical
properties), but i don't see that as much of a challenge.

> The problem using vCard4j parser module:
> The parsing creates a DOM and uses that DOM to create the java object
> and this will be a real performance penalty.

i don't think there's anything inherently inefficient in creating an
internal dom representation of a vcard object, especially if there's a
higher level wrapper api. i do think that vcard4j's explicit
dependency on the dom apis is clumsy, and i think it was probably for
reasons of laziness that the developer used a dom parser rather than
hand coding a parser from scratch. if we extended ical4j, i think we'd
be able to reuse ben's parser and simply extend it to create instances
of vcard types rather than ical properties.

> So I would suggest designing a custom vCard parser or something better
> than the above options.

as i mentioned earlier, i'd rather go with an existing library and get
basic carddav functionality working first, then look for the
bottlenecks and work to remove those. that's the general strategy
we've used for all of cosmo.

> Oh yeah its there. I was reading the greenbytes version of the draft and
> it shows me different xml elements :(. Thanks for pointing it out.

you were probably reading an old version of the draft.