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