[Chandler-dev] Recurrence in sharing

[Grant Baillie]

For the record, here is what Jeffrey told me (& Morgen) before he  
headed off on vacation. His idea is to enhance the sharing code to do  
the following when syncing collections:

- For non-recurring events, just make the changes to local objects,  
and let repository view merging do its work as before.

- For recurring events -- i.e. ones that have recurrence in the  
server version, or the local version -- don't change the local  
objects at all. Rather, have ICalendarFormat figure out what changes  
need to be made, and save the changes.

- Once the sharing code has merged the non-recurring events, it tells  
the ICalendarFormat to replay the changes it saved in the previous step.

The justification for this is that (in Katie's words, I think)  
"recurrence is hard": It creates a fairly complex graph of  
interdependent (and persistent) objects. The repository view  
mechanism basically has to merge two sets of changes to a general  
object graph, and trying to do so without knowledge of the complex  
domain of recurrence is likely to be error-prone.

That said, the "diff the server and local objects" part could be  
pretty tricky, and have some funky edge cases. Replaying the changes  
is at least similar to what we already have to do to handle user- 
initiated changes in the UI. Unless this week's sharing testing shows  
up tons of intractable recurrence-related issues, we're not going to  
have the time (or inclination) to do this for α3.

--Grant

On 13 Jun, 2006, at 15:31, Morgen Sagen wrote:

>
> On Jun 12, 2006, at 6:22 PM, Jeffrey Harris wrote:
>
>> Hi Folks,
>>
>> Normally I'd have a Skype conversation with Morgen about stuff like
>> this, but in an attempt to be more list-oriented, I'll put it in an
>> email. ;)
>>
>> I've been thinking about recurrence and sharing.  I was looking at
>> rewriting some of the import code to do a better job of preserving
>> existing items that don't need to be changed.  This got me thinking
>> about our approach to recurrence in sharing.
>>
>> I think, to preserve data integrity, we need to have a different
>> approach to recurrence sharing than other areas.  Ideally, we'd first
>> create a journal of server changes to a recurring event (if any  
>> exist),
>> then we'd compare them to a journal of changes since the last sync.
>>
>> This process is fairly complex, and most of the details are quite
>> specific to recurrence.
>>
>> I'd like to move much of recurrence conflict handling out of the
>> ICalendarFormat import and export layer and deal with it at a higher
>> level in the sharing process.  Morgen has been understandably  
>> reluctant
>> to add this complexity to sharing, but I think we're going to be  
>> running
>> into more confusing and difficult recurrence related merging bugs  
>> if we
>> don't work with recurrence more directly.
>>
>> Sincerely,
>> Jeffrey
>
> I'm open to doing whatever we need to make this work.  Can you  
> summarize the problems we currently face in recurrence sharing?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev