[Chandler-dev] Syncing of half-baked items

[D John Anderson]

On Sep 18, 2007, at 2:32 PM, Morgen Sagen wrote:

> As we've seen, it's possible to make changes to an item without having
> those items committed to the repository in a timely fashion, resulting
> in the sharing layer not seeing those changes and thus not sending
> them to the server until after the next commit.  In some cases this
> just means changes are slow to get to the server, but in other cases
> an item titled "New Event" is published (because the item creation was
> committed, but not the user's title change, etc.).
>
> I know some work was done to have detail view changes written back to
> the item after some period of time, but it looks like more work needs
> to be done to plug the holes where this isn't working (non-detail view
> changes?).

This task has been owned by a bunch of us. Bryan Stearns finally  
implemented most of the task, but there is still some work that  
remains. As he pointed out to on IRC:

http://chandlerproject.org/script/getIrcTranscript.cgi? 
channel=chandler&date=20070907&startTime=1502

and mentioned in a bug that he filed:

https://bugzilla.osafoundation.org/show_bug.cgi?id=10811#c4

Apparently, we need to call finishEdits with commit=True more often.

>
> In the past there was a proposal to have the sharing layer send a
> signal to (and wait for) the main thread to commit.  This seems
> problematic because what if the user is in the middle of editing
> something like a note body?  Do we want to commit in the middle of
> that, or somehow delay the background sync?  What if we turn the
> problem around and have the main thread in charge of scheduling syncs
> instead? It could schedule periodic syncs and also trigger syncs to
> happen just after local changes have been made, reducing the time it
> takes changes to get published.

I suspect that no matter who decides when to sync, the background  
thread or the UI thread, we will always run the risk of a race and  
it's consequences.

If we were able to fully implement Bryan's strategy of automatically  
committing changes, some time (say 30 seconds) after the last change  
occurred, it probably wouldn't matter too much whether or not the UI  
decided to sync or the background thread decided to sync. The worst  
thing that would happen is a 30 second race every hour (I think we  
sync every hour) where changes you just made weren't part of the  
sync. It that turns out to be a problem we could reduce the length of  
the race by not syncing during that 30 second period.

The bigger problem that Bryan ran into with he auto-commit strategy  
was the following: In some situations when the a pending change gets  
committed there is a side-effect of some other item being created. If  
we auto save in those cases, and the user hasn't really finished  
editing, we get extra items created that correspond to the unfinished  
edits. So, currently some edits aren't automatically committed  
because of this. I think fixing this might be possible but tricky.

John