Re: [Chandler-dev] Shared triage status for rearchitecture

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