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

Hi Jeffrey and Grant.

So exciting to finally be talking through this stuff!

I'm not entirely following the discussions, but have a few  
questions...so forgive me if my questions are not quite on target.

How would not syncing auto-stuff affect the web UI?

If I set an alarm to tickle a note to NOW. Would the web UI still  
show that the item had tickled to NOW, even though it doesn't have a  
notion of tickling? Would we need to implement the auto-triage  
functionality on the web UI to keep things in sync?

There is also the scenario of 2 desktop clients that are sharing  
Triage Status, but not alarms. If Desktop 1 fires an alarm and  
tickles the item to NOW, would Desktop 2 see the item as NOW even  
though Desktop 2's alarm hadn't fired yet?

Mimi

On Sep 23, 2008, at 3:56 PM, Jeffrey Harris wrote:

> 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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev