[psynaptic]

Thanks for posting those settings. This should keep it off my back now!

[ManasTungare]

Hi Ken,

Thanks for your reply; I applied those settings to solve the problem for my own computers.

In general, for other users, I feel that their frustration might be reduced if the dialog were not modal. The dialog text could also make a stronger connection between the cause and the effect. The "Show Client Registrations" button imposes an extra step whose relevance is not clearly obvious to the user. Why should I look at my client registrations? I don't want to.

Something that goes:

"Syncs taking too long? It might be because _ThisSpecificMachine.local_ has not been synced for the last _ASpecificNumber_ days. <Learn how to fix this (button)>"

at the top of the right pane could achieve both your goals: make it obvious, and keep it unobtrusive. There would be no need for an Ignore button, since it doesn't get in your face anyway.

I had tried to contact the Support Ninjas earlier, but I interpreted their response as a NOTABUG or WONTFIX. This is definitely a usability bug for those who, like me or the original poster, keep a backup laptop around and are not inclined to sync it more often than we currently do.

And thanks for the settings too, that does solve the problem in my own case, so I'm satisfied.

[wealthychef]

Originally Posted by JKT

Fwiw, my real world experience of this issue occurred over the holiday period where I was away from my desktop for 3 weeks - once I got back, because it hadn't been synched to my Desktop for such a long time, my OmniFocus database on my iDisk had ballooned from a few kb to over 8MB in size and synching took forever. I actually thought it had corrupted so after the first synch, I ended up nuking my database on my iPhone, compacting the desktop database and going through the rigamarole of posting it back to my iDisk and setting up my iPhone again. Of course, it wasn't until afterwards that I read on the forums that this wasn't necessary and the way to 'solve' it was to allow both desk and iPhone to synch and repeat it again within an hour so that the compacting would be performed automatically...

Doesn't this show that the Omnifocus "solution" is not really a solution but simply evidence of a flawed model of synchronizing? Another way of viewing this situation is that the choice to keep data all the way back to the oldest sync time is causing this situation. If that were relaxed or changed, the user would not need to be bothered. Omnigroup programmers take note -- a lack of programming foresight on your part should not constitute an emergency on mine. :-)

[Ken Case]

Originally Posted by wealthychef

Another way of viewing this situation is that the choice to keep data all the way back to the oldest sync time is causing this situation.

In the dialog, we do offer you the choice of not keeping data all the way back to the oldest sync time: you can unregister the old client, and collapse all that history which was being preserved for it.

The downside to collapsing all that history is that OmniFocus will no longer have any way to tell whether outstanding changes on that out-of-sync client are newer or older than the changes made on other machines (since they no longer have a record of what's newer and older). The upshot of this is that the next time you sync you'll be asked to make a "server or local" choice, and lose all changes from the side you didn't choose.

[Ken Case]

Originally Posted by JKT

Of course, it wasn't until afterwards that I read on the forums that this wasn't necessary and the way to 'solve' it was to allow both desk and iPhone to synch and repeat it again within an hour so that the compacting would be performed automatically...

By the way, the sync logic changes we're working on for OmniFocus 1.7 make it unnecessary to do this get-everything-in-sync-at-once song and dance. Sneaky peeks coming soon!

[wealthychef]

Originally Posted by Ken Case

In the dialog, we do offer you the choice of not keeping data all the way back to the oldest sync time: you can unregister the old client, and collapse all that history which was being preserved for it.

The downside to collapsing all that history is that OmniFocus will no longer have any way to tell whether outstanding changes on that out-of-sync client are newer or older than the changes made on other machines (since they no longer have a record of what's newer and older). The upshot of this is that the next time you sync you'll be asked to make a "server or local" choice, and lose all changes from the side you didn't choose.

I'm aware after having read this thread that there are workarounds. I'm asking you to consider that it's possible to have a model where the state of a client on my laptop does not affect the speed of the synchronization on my desktop or iPhone. Why do I have to choose between speedy backups and convenience? Can't I have both? Is this an intractable programming problem?

[Ken Case]

Originally Posted by wealthychef

I'm asking you to consider that it's possible to have a model where the state of a client on my laptop does not affect the speed of the synchronization on my desktop or iPhone. Why do I have to choose between speedy backups and convenience? Can't I have both? Is this an intractable programming problem?

Oh, sorry: yes! Of course you should have both speedy backups and convenience! (I want both too.) My previous response was simply meant to address the suggestion that the problem was that we were keeping data all the way back to the oldest sync time.

The big problem right now is actually that we're keeping data longer than that, because the sync algorithm didn't know how to compact a portion of the transaction graph across multiple branches—it had to wait until the graph joined back into a single path, which only happened when every client was in sync at the same time.

Over the last month we've been working out a new compaction algorithm which lets us compact across multiple branches, but it requires some changes to existing clients so that they could understand the new merge transactions which join branches together. As soon as those changes have been deployed (on the iPhone in v1.2.1—published yesterday—and on the Mac in v1.6.1—hopefully published soon!), we can let this new algorithm out into the wild.

I have three test cases for this (all based on real data): the first compacts 1,930 transactions into 741; the second compacts 51 into 18; the third compacts 755 into 66(!). That first test case still has a lot more transactions than I'd like to see, and I have some other work in progress which will help reduce things even further, but it's already a reduction of 65% - 91%—so it's definitely a big step in the right direction!

[wealthychef]

Originally Posted by Ken Case

Oh, sorry: yes! Of course you should have both speedy backups and convenience! (I want both too.) My previous response was simply meant to address the suggestion that the problem was that we were keeping data all the way back to the oldest sync time.

...
Over the last month we've been working out a new compaction algorithm...!

Thanks for the clarification! It will be a relief to be freed from these little nags. I appreciate your work!

I suggest to have a less invasive warning, rather than a dialog box popping up and blocking your activities.

Maybe a sign on the toolbar: you could have the "sync" button (which already shows an exclamation mark sometimes) showing something, and/or change color into red, or something along this lines. In this way, the warning is clear, but it does not stop your activities when you decide to ignore it.

What do you think?

cheers
--e.

[mtnygard]

I got this nag so often that OF trained me to completely ignore the dialog. In fact, I get nagged by both computers, so I get it twice as often.

Wouldn't you know it, I actually did have an old iPhone still registered.

The annoying frequency of this nag caused me to disregard it, which in turn caused me to overlook an actual problem. Classic case of the "boy who cried wolf."