[Chandler-dev] Syncing of half-baked items

[Andi Vajda]

On Tue, 18 Sep 2007, 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?).
>
> 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.

+1 to the UI asking for syncs.

Andi..