[Chandler-dev] [App/Design teams please read] Uncommitted changes
and background syncing
Katie Capps Parlante
capps at osafoundation.org
Mon Mar 27 16:48:38 PST 2006
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 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
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?
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. I don't think the user has
the expectation that every change is sync'd instantaneously.
Are there other end user consequences? At first blush, this seems like a
perfectly reasonable design, as long as the main view commits happen
More information about the chandler-dev