[Dev] The Chandler/Cosmo sharing format

Brian Moseley bcm at osafoundation.org
Mon Mar 6 16:50:17 PST 2006


On 3/6/06, Lisa Dusseault <lisa at osafoundation.org> wrote:

> If we were sharing email and tasks as well as events to a CalDAV-only
> server, then yes, all the stamped information besides the event
> information could be stuffed into x-properties and/or attachments.
> But actually, the problem comes when a server is capable of
> understanding events as one kind of resource, tasks as another kind
> of resource, and possibly in the longer run email as a third kind of
> resource.  If we had a general server capable of understanding those
> different types, we wouldn't want to make one type "dominant" (the
> event) and hide the information for the other kind in extension
> properties.

yeah, that's what i was attempting to point out with my rhetorical question :)

> It may be that stamped items are the one thing we have to share as 2
> separate resources to maximize interoperability.

let's try as hard as possible to avoid that. we don't want syncing to
cause a huge explosion of (webdav) resources on the server because
stamping winds up being so popular (i predict).

> 1.   Microsoft invented a WebDAV extension to combine multiple
> requests in a transaction:
>         LOCK with special syntax to start transaction and get transaction ID
>         PUT #1 with Transaction header to do the first resource created in
> the transaction
>         PUT #2 with same Transaction header
>         UNLOCK with transaction ID to commit the changes

that's how jcr-over-webdav transactions are implemented.

> Yes, but maintaining such formats across releases and as requirements
> change turns out to be very painful.

i don't buy it :) morgen's putting together a concrete proposal for an
xml format, and i think the burden of proof is on those who say nay to
it.

> We want version 0.7 of chandler to
> interoperate with people running 0.8 and so on.  Which version of
> Chandler becomes the one whose internal format becomes externalized
> and set in stone, and why that version?

a requirement of the format is that it not be sensitive to changes in
chandler's or cosmo's repository. morgen's paying careful attention to
that, if i heard him right on the phone today.



More information about the Dev mailing list