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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
