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
