[Chandler-dev] Chandler as CalDAV client

Andi Vajda vajda at osafoundation.org
Tue Feb 13 18:27:54 PST 2007


On Tue, 13 Feb 2007, Grant Baillie wrote:

> I think 3) is the most sensible, too. Since the EIM records were written with 
> iCalendar in mind, I'm hoping that it's not going to be too nasty to 
> implement, but I haven't dived into any EIM code lately.

+1

Keeping time-travel merging around is asking for trouble.

Andi..

>
> --Grant
>
> On 13 Feb, 2007, at 16:43, Morgen Sagen wrote:
>
>> As you know, we've been rewriting most of the sharing code to use a new 
>> sharing model (External Information Model, or EIM), a new protocol 
>> (Morsecode), and a new serialization format (EIMML).  Of course, Chandler 
>> needs to remain a CalDAV client, and so we have at least three options:
>> 
>> 1) Continue to maintain the old CalDAV code by ripping out the old XML fork 
>> which makes use of the .chandler subdirectory in the CalDAV collection on 
>> the server, and keep using the repository's view-time-travel feature to 
>> merge in changes, or...
>> 
>> 2) Use a slightly modified version of (1) which doesn't use 
>> view-time-travel, but rather puts the responsibility for merging and 
>> detecting conflicts on the calendar code, or...
>> 
>> 3) Use a more modified version of the ICalendar code but *on top* of the 
>> EIM-based sharing layer.  There would be a new layer which takes an 
>> icalendar body and breaks it down into EIM records, and vice versa.  Those 
>> EIM records could then be diffed and merged and participate in conflict 
>> resolution.
>> 
>> The huge problem with (1) and (2) is that they don't leverage the merging 
>> and conflict resolution work that EIM handles, and therefore we would have 
>> two different sharing worlds within Chandler.
>> 
>> I think if we take the (3) approach, in the future other developers can add 
>> on their own conduits which produce and consume EIM records and thereby get 
>> merging and conflict handling for free.
>> 
>> So I think we need to do (3), I just don't know yet how much work that is.
>> 
>> ~morgen
>> 
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> 
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev


More information about the chandler-dev mailing list