Grant's concept of not syncing the auto stuff is great. Grant and I talked about this more in IRC:
http://chandlerproject.org/script/getIrcTranscript.cgi?channel=chandler-rearch&date=20080923&startTime=1535&endTime=1555 Grant Baillie wrote: > Hi, Jeffrey > > I have been pondering this somewhat, too, but I think the lines I'm > thinking along involve just never syncing automatic changes. Are there > cases where we ever actually need this information? (Possibly web UI > users need it, I'm not sure). > > --Grant > > On 19 Sep, 2008, at 18:29, Jeffrey Harris wrote: > >> There have been a variety of problems with the interaction between >> triage status, the passage of time, and syncing multiple desktop >> clients. What follows is my thinking about how to fix those problems. >> >> There are two main things I think are broken in the existing triage >> sharing code: recurrence and distinguishing between automatic and >> user-originated changes. >> >> The recurrence problems spring from the desktop model of creating a >> database record for every occurrence rendered in the UI. This >> encouraged us to create and destroy dozens of "modifications" to >> recurring series that really only involved normal state following the >> passage of time. >> >> The other main problem is that we don't distinguish between automatic >> changes to triage status and manual changes. Here's a scenario: >> >> - I'm sharing with myself and an item's alarm fires, moving the event to >> NOW >> - I mark the item as DONE and sync client 1 >> - I open client 2, it fires the same alarm and moves the event to NOW >> - I sync client 2, the local NOW beats the remote DONE, even though the >> DONE was a manual change. >> >> Another situation that may trigger this is if client 2's sync happens >> before alarms fire, causing Chandler to apply the remote DONE change >> first, then move the item back to NOW. >> >> Add change_was automatic/manual field >> ------------------------------------- >> >> To improve things in the non-recurring case, I think it's enough to add >> an additional record to triage status which notes whether the most >> recent change was made automatically or manual. We should also make >> sure alarms fire before sync happens, at least during startup. >> >> When syncing, I think triage status conflicts should be automatically >> resolved with the following heuristic: >> manual beats auto >> local auto beats remote auto >> remote manual beats local manual >> >> There are also minor problems with what pops to now; not every EIM >> change should trigger pop-to-now. For triage-status, >> - anything becoming NOW (this actually isn't working right now), or >> - when a manual triage status is changed >> should trigger a pop-to-now. >> >> Recurrence >> ---------- >> >> The recurring case is, of course, a little harder. The general concept, >> though, is fairly simple. All triage status information should live on >> the master, not on individual modification records. Most occurrences >> will be unspecified, which will mean they have an implicit triage status >> of DONE or LATER, depending on where they sit relative to the current >> time. >> >> Triage related fields on recurrence master: >> - lastPastOccurrence (already exists) >> before this date, implicit occurrences are DONE, after, LATER >> - auto_done (new) >> there's recently been talk of allowing a user preference for >> whether events are automatically marked DONE. This is reasonable, >> but it makes it hard to guess whether an implicit occurrence was >> marked DONE automatically or manually, so we should be explicit >> - triaged_occurrences (new) >> a serialized dictionary of recurrence-id: triage status, >> manual/automatic tuples >> >> I'm assuming we'll throw non-standard triage statuses away if there's a >> rule change or dtstart change, and that we won't bother syncing >> triageStatusChanged, which changes how an item is sorted. >> >> Conceptually, local minus original gives you small set of local >> occurrences whose triage statuses changed from X to Y, either manually >> or automatically. Similarly, remote - original gives a small remote set >> of occurrence changes which can be merged with the local set. >> >> This behavior looks different from the existing EIM diff implementation, >> I'm hoping we can extend EIM diffs to do a special diff operation for >> recurrence master records. > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > 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
