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
