[Chandler-dev] [App/Design teams please read] Uncommitted changes
and background syncing
morgen at osafoundation.org
Mon Mar 27 18:16:30 PST 2006
On Mar 27, 2006, at 4:48 PM, Katie Capps Parlante wrote:
> Hi Morgen,
> Morgen Sagen wrote:
>> I'm working on background syncing, and have much of it working
>> now, but an issue has come up: what to do about *uncommitted*
>> changes that conflict with changes the new background syncing
>> thread has committed. For example, say I change the title of a
>> calendar event (but that change has not been committed to the
>> repository), and someone else changes the title of that same event
>> and syncs their change to the server. In the background, the
>> sharing layer fetches the remote change and commits it to a
>> private repository view. What happens next is the OnIdle method
>> in Application.py will do a refresh( ) on the main view which
>> picks up that change and there will be a merge conflict; currently
>> OnIdle doesn't handle conflicts, and an exception is raised.
> Could you summarize what you are doing now to handle merge
> conflicts on the background syncing thread? Presumably one option
> is to use the same handler. Are there other options?
The background syncing procedure is:
1) Roll back the sharing view to the way it was when we last finished
syncing, using sharingView.itsVersion = x
2) Get remote data and apply those changes to items in the sharingView
3) Commit the sharingView; commit(mergeFunction) first does a refresh
( ), bringing in all committed changes from other views, and calls
mergeFunction for any detected conflicts. The current mergeFunction
notes the fact that a conflict occurred and applies the remote change
(overwriting the local change). After this step, changes brought in
from the server are now available to other views.
4) Put any locally modified items to the server
5) Commit to record the latest ETAGs and other bookkeeping data
The OnIdle refresh( ) could simply do what the sharing mergeFunction
does, which is to let changes from other views overwrite local
changes to the main view. I'll go ahead and do that if there are no
objections. Conflicts could be coming from other views besides
sharing (eventually), but so far I think we have carefully coded
>> The other related issue is when to make the user's changes
>> available to the sharing layer. When the user changes a field in
>> the detail view, for example, there is no commit( ) performed on
>> the main repository view and therefore the sharing layer doesn't
>> yet see that change. Only after a main view commit( ) happens can
>> the sharing layer pick up the user's changes.
> In the detail view case, when does the main view commit happen? Is
> it in a reasonable time frame from the end-user's point of view?
I don't know if/when the main view commits automatically. For
testing, I have been using the 'Test | Repository | Commit' menu
item. Thanks to Alec for cleaning up the Test menu, by the way! :-)
> If I understand correctly, we have a window of time where changes
> that the user has made are not yet being sync'd to the server.
> Presumably this would be true whether or not all changes were
> committed instantly on the main view thread -- the background
> thread looks for changes at its own pace, not on every change in
> the ui.
Yes, the background thread is on its own pace, picking up whatever
changes happen to be committed from other views at the time the sync
> I don't think the user has the expectation that every change is
> sync'd instantaneously.
Ok, I just wanted to make sure people were aware of this issue. The
only commit I *know* happens is when you quit Chandler, so
theoretically the user could make a change and not have that change
synced until the next time they run Chandler.
> Are there other end user consequences? At first blush, this seems
> like a perfectly reasonable design, as long as the main view
> commits happen reasonably frequently.
It's the commit frequency I don't know about. Apps team?
More information about the chandler-dev