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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
