Hi Mimi, > Would it be difficult to treat 'split recurrence series' the same way we > treat modifications to individual events? e.g. Just because I change the > Title on instance 3 of a recurring series doesn't mean that the next > time I make a 'this and future' change to say the 'location' field, I > don't want instance 3 to be affected as well. It seems like if we're > going to start keeping track of modifications on a per-attribute basis, > we should do that for all kinds of modifications, including date/time > modifications that split the recurrence series into multiple parts.
It's quite difficult, unfortunately. Splitting recurrence after a THISANDFUTURE change is a huge simplification of the recurrence code which is still very complex despite that simplification. As it happens, Grant was looking into maybe doing this despite the additional complexity because it helps sharing conflict resolution a lot. Note that if we do that it'll have a big impact on Cosmo's recurrence efforts, too, so since the cost would be high I think it's likely for preview we'll try to come up with an alternative simplification for recurrence conflict resolution. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
