[Chandler-dev] Chandler as CalDAV client

Morgen Sagen morgen at osafoundation.org
Tue Feb 13 16:43:00 PST 2007


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



More information about the chandler-dev mailing list