[Cosmo-dev] Schema file changes for CardDav support

[Brian Moseley]

On 7/5/06, Vinubalaji Gopal <vinu at osafoundation.org> wrote:

> As per the carddav spec
> (http://ietfreport.isoc.org/cgi-bin/id2pdf?f1=draft-daboo-carddav-00.txt),
> I propose to add the following new nodes and properties in the schema
> file:
>
> <adbk = 'http://osafoundation.org/adbk'>
>
> /* Assuming that the url need not work and just provides a unique
> namespace for the entire repository. None of the other url's like
> calendar, ticket or cosmo work AFAIK.
> */

that's correct.

> /* adbk:description property, section 5.2.1 of the CardDav Spec */
> [adbk:collection] mixin
>   - adbk:description (string) copy
>
> /* adbk:uid property, section 5.3 of the CardDav Spec */
> [adbk:resource] mixin
>   - adbk:uid (string) mandatory copy

you'll also want to have a language property similar to
calendar:language. this specifies the locale/language codes for the
human language used with the calendar description and is represented
in dav messages as the xml:lang attribute of the
CALDAV:calendar-description property. cosmo doesn't give caldav
clients any way to set the calendar language yet, and simply
initializes this property to the system's default locale/language. you
should do the same for now.

> Apart from this, other properties for the adbk:resource like the
> adbk:fn, adbk:ln will be set based on the vcard file.

agree. you'll want to implement this with the same "flattening"
technique we use for icalendar properties, tho the flattened names for
contact properties will likely be simpler.

> I am adding the copy attribute for historical reasons, since we might be
> using versioning at some point or might make a global change to remove
> the copy attribute.

yep.

> The complete design document (also includes a list of files that needs
> to be changed) can be found at:
> http://wiki.osafoundation.org/bin/view/Projects/CosmoCardDav

for the moment, cosmo doesn't implement webdav class 2 (locking).
we'll add that for all dav-based protocols in a separate pass. same
for webdav acl. i don't think it's likely that we'll implement deltav
for cosmo 1.0.

i think we should pass on the adbk-sync report for now. we're going to
have to find a way to implement efficient synchronization for all
content types across the ecosystem, and we can look at this report
when we do that.

eventually we're going to want to allow a single collection to
function as both a calendar collection and an addressbook collection,
but you shouldn't worry about this for now. using mixin node types
sets us up at the repository level, but we'll need to do additional
protocol work to support this feature.

i suggest not worrying about creating a base class for calendar and
addressbook collections and resources. we can refactor if we decide
that the model would really be clearer that way, but i don't think
it's a big issue.

there's one additional implementation consideration: jcr-server
doesn't use cosmo's service layer to persist data. instead it uses
it's own "i/o" subsystem. one creates implementations of the
o.a.j.server.io.IOHandler interface that convert data provided in
ImportContexts into nodes stored in the repository, and vice versa.
see o.o.c.dav.io.DavCollectionHandler and DavResourceHandler. you'll
need to add code to these classes to import and export addressbook
collections and vcard object resources.