What should I do about "Client has not been synced" warnings? [Fixed: see thread] [Archive]

whpalmer4

2009-01-13, 10:39 AM

Sync the things once a week and you won't have the complaints. Or are you saying that these machines go more than a week without being on?

If you have a client that you really don't expect to use for a while, you could simply delete its registration (after syncing it, of course). Then when you need it, turn sync back on and when it complains that the files don't appear to match any longer, be sure to select the server or remote copy.

There's no readily apparent means to change that warning interval. Use Help->Send Feedback to request one.

stacecom

2009-01-14, 11:31 AM

Sync the things once a week and you won't have the complaints. Or are you saying that these machines go more than a week without being on?

That's what I'm saying.

If you have a client that you really don't expect to use for a while, you could simply delete its registration (after syncing it, of course). Then when you need it, turn sync back on and when it complains that the files don't appear to match any longer, be sure to select the server or remote copy.

I guess I'll have to try that. It's not ideal, but it'll do.

There's no readily apparent means to change that warning interval. Use Help->Send Feedback to request one.

I will. I don't even want to change the interval, I just want the "ignore" button to *actually* ignore it and stop telling me about it.

Brian

2009-01-14, 03:27 PM

We keep bugging you because until those older client files are removed by a later sync or by nuking them, your sync database won't compact. We keep all the transaction files around all the way back to the least recent sync so we can insert transactions from that machine when it eventually does.

Those extra files make every sync for the machines that *are* synching take longer. If someone that doesn't understand what's going on selected a perma-ignore option, they'd create a situation where their synchs eventually became unbearable; they'd blame OmniFocus, not the checkbox they clicked in the Ignore dialog three months ago.

I'm pretty sure we have a feature request open for nagging less frequently, though; send the ninjas an email if you'd like to add your voice to it.

JKT

2009-01-15, 12:17 AM

psynaptic

2009-02-12, 05:38 AM

This happens to me on what seems to be a daily basis. I get a notice saying it's been so long since my last sync of a client. It always happens when I'm trying to type and really bugs me. If I don't want to sync my device (iPhone) I shouldn't have to. I hate this warning. Please sort it out.

whpalmer4

2009-02-12, 07:46 AM

Well, why don't you just sync the device in question? Doing so once per week will keep that warning away. Or, if you don't plan to do that, go to the Sync preferences and delete the device until such time that you want it to be synced (though you'll lose any outstanding changes on the device if you don't sync first). I'm not sure what the point of having your data on your iPhone more than a week out of date would be...

Brian

2009-02-12, 06:38 PM

I think we've had some discussions of moving the "hey, it's been a while" to the start of the app, rather than when we try to sync. Of course, if we changed that, the folks that never quit OmniFocus would never see the notice. I guess we could pop it up if folks tried to sync manually, but some folks never do that, either.

It's a tough one. On the one hand, folks are annoyed by slow syncs. We don't care about the out-of-date info on that one device - what we care about is the fact that all the devices that they are syncing are taking longer to do so until it gets caught up.

However, this thread is evidence that telling folks why their syncs are slowing down (in this manner, at least) annoys them, too. Worse, the message isn't effective; folks don't understand how to stop it (or are choosing not to do so). Result: some folks are actually annoyed more frequently than if we did nothing. Not good.

It would be helpful if the folks that are hitting this message and are annoyed by it could let us know what would work better. Believe us - the goal here isn't to be annoying. :-)

justG

2009-02-12, 08:05 PM

Thanks @OmniFocus (http://twitter.com/OmniFocus) for directing me to this thread.

I think we've had some discussions of moving the "hey, it's been a while" to the start of the app, rather than when we try to sync. Of course, if we changed that, the folks that never quit OmniFocus would never see the notice.
That works for me.

It would be helpful if the folks that are hitting this message and are annoyed by it could let us know what would work better.
Your "thinking aloud" solution proposed above would work for me but it'll no doubt increase support requests from people who don't understand why their syncs are so slow.

1Password's unlock screen includes an option to store your master password in your login keychain. As soon as you enable this option, you're warned of the inherent security risk. You have to agree to this to continue. Might you consider a "don't remind me again" option that, when clicked, displays a warning about the consequences of continuing? Something concise and bold that's not easily ignored.

Ken Case

2009-02-12, 10:51 PM

There are two hidden defaults which control how often OmniFocus complains about stale clients:

SyncStaleClientInterval (factory setting 604800 seconds, or one week) says how stale a client has to get before OmniFocus complains the first time.

SyncStaleClientComplaintInterval (factory setting 172800 seconds, or two days) says how frequently to remind the user after the first complaint.

So if you want your first warning after two weeks (instead of one), and subsequent reminders every four weeks (instead of two days), try entering these commands in a Terminal window:

defaults write com.omnigroup.OmniFocus SyncStaleClientInterval -float 1209600
defaults write com.omnigroup.OmniFocus SyncStaleClientComplaintInterval -float 2419200

After you've done this, restart OmniFocus so it notices the new settings, and you'll be warned much less frequently!

psynaptic

2009-03-18, 10:29 AM

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

ManasTungare

2009-03-27, 02:58 PM

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

2009-04-01, 04:08 PM

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

2009-04-01, 04:15 PM

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

2009-04-01, 04:22 PM

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

2009-04-01, 04:54 PM

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

2009-04-01, 07:02 PM

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

2009-04-01, 07:45 PM

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!

franconi

2009-07-07, 01:47 AM

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

2009-07-22, 08:18 AM

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."

whpalmer4

2009-07-22, 08:59 AM

Why did you choose to ignore the message in the first place?

Ken Case

2009-07-22, 11:23 AM

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."

I've been thinking about how to improve that dialog to make it more relevant, perhaps saying something like this:

To keep syncing performance optimal, Omni recommends that you keep no more than 150 transactions in your sync history. Because you haven't synced "oenone" in over a month, your sync history is currently using 2,500 more transactions than would otherwise be necessary.

You can solve this by syncing "oenone" or by unregistering it. If you choose to unregister it, it will automatically resynchronize the next time you use it—but any local changes which haven't already been synchronized will be lost.

And then, of course, not bothering you with this alert at all unless your sync history really was over 150 transactions.

Would that help?

jonmarsh

2009-08-14, 01:41 AM

Would that help?

It would certainly help me!

This dialog box seriously annoys me. I use OmniFocus from 4 different devices depending on which one is closest at the time. I love it that I can use OmniFocus like this.

However I don't make that many edits and I only use 1 or 2 of the devices regularly. When I click ignore the sync only takes a few seconds. Therefore I spend a few seconds clicking away this dialog box every day or 30 seconds deleting the currently unused registration just to save my Macs from doing 0.1s of extra work. That's a bad piece of design. If it must nag, it should do so only when there is a real problem and I should not have to trundle off to the preferences screen in order to solve the problem (i.e. add the option to un-register the client to the nag dialog box).

I look forward to the new and improved sync in forthcoming versions but in the meantime I shall apply the settings in this post so that I get nagged less frequently.

Jon.

iNik

2009-11-25, 07:05 AM

I just added this option to the "Secrets" database and preference pane (http://secrets.blacktree.com) so that folks can avoid "defaults" if they want to.

Also, one year in seconds is 31540000 -- probably a useful amount to just keep the monkey off your back. (Personally, I have one computer set to the normal setting, and the others bug me annually now)

Kevin R

2010-01-09, 10:15 PM

Sorry, but the workarounds to reduce the aggravation level of the complaints aren't good enough. OmniFocus has absolutely no business complaining in the first place, at least not with modal dialog boxes.

(The suggestions to only nag at start-up would not be an improvement. So many times I start up OmniFocus precisely because I've remembered a task that I need to type in before I forget. But wait, there's that annoying box again. My hands need to leave the keyboard, fumble for the mouse, dismiss the dialog box, go back to -- Congratulations, you've made me forget what I was going to type. So much for getting all my stuff out of my mind and into a trusted system.)

Yeah, I get it. It's a good idea to sync all my devices regularly for technical reasons. But can you honestly tell me that keeping all my devices in sync is so vastly more important than every single other thing I have to do in my life that it alone should get to nag me completely outside my normal task-management workflow?

Is it so vastly more important that it alone should get to force itself into my consciousness at seemingly random times rather than when I'm ready to choose my next task (and my only way of even slightly modifying the times isn't with the OF features I use for everything else, but to fiddle with secret options using arcana of the operating system, repeating on every device I own)?

Is it so vastly more important that it alone should get to yank my attention away from whatever other application I'm using on my computer -- not only ignoring context, but when I'm guaranteed to be in exactly the wrong context to do anything about it?

If you're so firmly convinced that regular syncing is important, have OF slip reminders into my inbox so that I can choose to deal with them, or not, the same way I do all my other tasks. (And provide a preference to turn that behavior off.)

Nagging users over minor technical issues with modal dialog boxes isn't just bad interface design and incredibly rude, it fundamentally violates the GTD philosophy that OF is allegedly made to support.

whpalmer4

2010-01-10, 06:06 PM

Nagging users over minor technical issues with modal dialog boxes isn't just bad interface design and incredibly rude, it fundamentally violates the GTD philosophy that OF is allegedly made to support.
Where is it that David Allen & Co. describe proper user interface design for GTD? I agree that modal dialogs can be annoying (my pet peeve is the sync client display blocking the application from quitting, when I'm the one who requested the display) but "fundamentally violates the GTD philosophy"?

joseph.gruber

2010-03-24, 09:50 AM

How about an option when the message first comes up that says something to the effect of. Cancel and don't remind me again until (xxxx -- drop down).

I'm glad I found this thread because this alert is very annoying to me since I have the iPhone app that I don't frequently use.

ctawn

2010-04-02, 04:08 PM

can we change it to a million years?

like the first poster, i don't care if my laptop that i rarely use hasn't been synced. and i don't care either about the iphone. until the rare occasion i want to use either. after reading this thread i understand the issues better, so thanks. but still i would prefer never ever to get that annoying warning and wait longer to sync when i do use those other devices. life is stressful. too much to keep in sync. on the laptop if there could be a daemon running that would solve it. on the iphone not so sure. the iphone sync situation generally sucks as you have to sync every app individually. palm was much better with conduits.

whpalmer4

2010-04-02, 05:58 PM

ctawn

2010-04-02, 07:23 PM

ctawn, did you bother to read Ken's posts where he described how to set the behavior? It's all there. Just type in any 11 or 12 digit number that strikes your fancy and it won't bother you for years (except for your database getting larger and slower).

If you have clients you rarely run and don't care if it takes a bit longer for them to sync when they start, use the show clients display in the sync preferences on a machine you do use frequently and simply delete those rarely used clients. The client(s) you do use regularly will perform better, and the ones you don't use regularly will perform no worse.

yes, i read it, and changed one end to whatever defaults he set. sorry didn't feel like calculating seconds that much. now the other end(s) -- as one poster said, guaranteed to not be the right context to do that ;-) i like the idea of putting the reminder as a task rather than a modal dialog.

the option to delete and restore clients all the time is also a time suck. just ironic for an app that's supposed to help manage my time is all.

so what happened, a year ago there was a post about a new algorythm for sync that would eliminate this need. and especially with < 150 transactions. i would say i don't use OF enough to approach that in an average month. so that would be groovy.

Miroboru

2010-05-06, 01:22 AM

My main complaint about this "feature" is the tendency of the dialog box to hide under some app in another space if Omnifocus decided to do its warning e.g. during the night. Finding the box involves hiding the rest of my apps - OF is patently unresponsible untill the box has been clicked.

This may very well be a feature of Cocoa for all i know and hence not something Omni can do much about, but it is still irritating. Maybe you should print the warning in a small box while doing the syncing, making it disappear when the sync process is done?

Ken Case

2010-05-07, 04:56 PM

Xeri

2010-05-30, 12:50 AM

whpalmer4

2010-05-30, 05:16 AM

Wait, WHAT? Did you just say that OmniFocus is being changed so that it will automatically drop the unsynced client and force me to lose any local changes on it without even asking me?!? How is that possibly an improvement?!? NO NO NO NO NO NO NO!!!!! DO NOT DESTROY DATA!!! I'd rather have the secret setting to defer the nag screen than have my data automatically destroyed for me. I have five instances of OmniFocus going between iPhone, iPad, and two computers. I simply cannot always remember to start something up every few weeks just to make sure stale changes get synced out.. this does not imply that I don't care about those changes, though. User data should never be put in such haphazard jeopardy!
Radical idea: someone should write a program that could help you to remember to do important things such as backups, syncing OmniFocus clients every two weeks, etc. In the meantime, you could use OmniFocus to help you remember...

I would argue that if you are making changes on a device and cannot be bothered to make sure one (1) sync is done on that device in the three weeks after making a change, you have demonstrated that in fact you don't care about that data. After all, what is the point of making the change in the first place, if you aren't going to propagate it to the rest of your devices? Are you going to remember that stranded change when you next look at that project on another device?

Xeri

2010-05-31, 01:34 AM

I don't really care how you want to use these tools; I paid $100 to use these tools, trusting that they wouldn't wantonly destroy my data. Dropping clients without even asking me is doing precisely that. At that point I'd start to feel like I really want my money back if my data is going to be put at such risk by future software updates. I didn't sign up for this kind of misbehavior.

whpalmer4

2010-05-31, 06:09 AM

I agree, you don't have to convince me! You do, however have to convince Ken, and not being able to effectively counter the questions I raised about your apparent workflow makes me think that you are likely to be on the losing end of an engineering tradeoff. It isn't usually possible to please everyone, and your stance is going to make you an outlier compared to the much larger numbers of people who want their syncs to be reliably fast, and don't insist on the right to make changes on a device they never sync and yet not lose them. Omni being Omni, if you stubbornly insist that this means more to you than the ability to keep using OmniFocus, you may well get your money back. Putting in an action to remind you to do a sync every two weeks seems like an easier project than finding and migrating to a new task management system!

Ken Case

2010-05-31, 11:15 AM

Wait, WHAT? Did you just say that OmniFocus is being changed so that it will automatically drop the unsynced client and force me to lose any local changes on it without even asking me?

Yes, OmniFocus will automatically drop devices which haven't synchronized in three weeks—but no, that doesn't lose the data on those devices!

When you next attempt to synchronize a dropped device, you'll be asked whether you wish to replace its database with the current server copy. You can cancel the sync at that point and look at its local database before deciding whether to replace it. (To easily review recent edits, I recommend using a context-mode "Recent Changes" perspective that groups and sorts all items by their Changed date.)

If you do elect to replace a local database with the server copy, OmniFocus for Mac will make a backup of your old local database just in case you realize later that you missed something. (You'll find it named something like "OmniFocus Prior To Resynchronizing on [date]".) OmniFocus for iPhone can't do this automatic backup (because it doesn't have any mechanism for accessing alternate databases the way the Mac app does), but you can always email your database to yourself (http://people.omnigroup.com/kc/DebugOmniFocus/EmailDatabase.html) and open it on your Mac.

Finally, I should point out that OmniFocus tries to automatically sync local changes to the server within one minute, so in my experience it's uncommon for out-of-sync devices to have any local changes. (They're generally just out of date!) But if they do have some local changes (perhaps they were offline while those changes were made and haven't been synced since), please rest assured that those changes will not be dropped without warning. (That would be antithetical to the notion of a trusted system!)

(The next step I'd like to take is to have OmniFocus automatically determine whether any local changes have been made. If there are no local changes, OmniFocus doesn't need to prompt about whether to replace the local database or not—it can just do it. And if there are local changes, perhaps OmniFocus could automatically reapply those changes after it gets back in sync.)

Xeri

2010-05-31, 11:30 PM

That is the root of the concern, yes: a device which may have edits done while the device is offline. How is it not considered losing data if my choices seem to amount to "Don't sync this anymore" or "Throw away whatever you had on this device and overwrite it with the server data, then reenter the deltas by hand"? I don't consider it to be an effective alternative if I have to reenter the data that was on the device in question. What, then, was the point of me entering the data in OmniFocus to begin with? What is the impetus for this change in the first place? Why can users not decide for themselves that they do or do not want this behavior? By my estimation this all amounts to a bunch of added complexity for some users who understand what's going on and don't quite need this level of hand-holding. I also take significant issue with the statement "But if they do have some local changes (perhaps they were offline while those changes were made and haven't been synced since), please rest assured that those changes will not be dropped without warning." It seems an awful lot like, by the time I'm finding out that something has happened, the device has already been dropped from the coherency domain by other instances and the damage is already done, forcing me to do a bunch of extra work to clean up the mess that I don't think needed to be made in the first place. Can you please make this behavior optional? I understand that this is a desired behavior for most users who don't understand the nuances of what's going on here, but for those us of who do can we get an opt-out? Also, can the mobile clients also drop other clients like this or will it just be the desktop software that is capable of this?

chrispix

2010-06-16, 10:51 PM

From the upcoming sneaky peek build (http://www.omnigroup.com/products/omnifocus/download/sneakypeek/)'s release notes:

OmniFocus will no longer prompt users to synchronize devices which haven't synchronized in over a week. Instead, if the sync database needs to be compacted (i.e. it has over 250 transactions in its sync history) OmniFocus will automatically unregister devices which haven't synchronized in over three weeks.

Yikes, please don't make this change, or at least make it possible to disable this behavior. I was glad to find the hidden options in your post #10, and now I'm glad I read ahead. It doesn't matter how I use it--I NEVER want OmniFocus to decide to unregister my device, which might cause me to have to use some workaround just to preserve data.

Here's how I use OmniFocus: I have a copy on my home desktop, which I make changes to about once every 2 weeks. I have a copy on my iPhone, which I make changes to more frequently. But I almost never use my iPhone version at home, as it's easier to just use it on my desktop. And the tasks I enter and modify on my desktop (like paying bills) tend to be different from the ones I enter and modify away from home on my iPhone (like shopping lists).

So I don't care that much if they're out of sync for a while, and I tend to only actually open the iPhone app at home when I'm intending to sync. But I still do want to be able to sync when I want to, and keep one database, not a home one and an on-the-go one.

If the issue you're trying to solve is poor sync performance, perhaps a better solution would be to display a message on the syncing device during a slow sync that says "Your sync is taking a long time because you haven't synced in a while. Sync more often for faster syncs." That would let me decide whether the trouble of syncing more often is worth the benefit of faster syncs, instead of you making a fairly drastic decision for me.

Yes, OmniFocus will automatically drop devices which haven't synchronized in three weeks—but no, that doesn't lose the data on those devices!

How can that be? It sounds to me from your description and my usage patterns that my choices would be to either a) let it replace the database on my iPhone, in which case I'd lose local changes, or b) email myself my iPhone database, and somehow figure out what's changed and manually copy things over to my desktop database? Both of those are awful solutions. If they're my only choices, I won't be updating to the version with this change.

chrispix

2010-06-16, 10:58 PM

BTW, I'd love to be able to just use a remote WebDAV server and sync that way, so I'd effectively be synced whenever I open the iPhone app, but I've tried to set it up and ran into enough problems that it wasn't worth the effort.

ctawn

2010-06-17, 04:23 AM

I'm using MobileMe to sync and still have all these issues. Why doesn't OF use the normal OS X sync services in the first place? Then I think there would be none of these issues.

chrispix

2010-06-17, 10:53 AM

It struck me later that you're probably designing for the use case where the client is gone and really isn't coming back. In that case, perhaps a banner at the top of the OmniFocus window would be better than a modal dialog. I'm thinking of something like what you see at the top of http://stackoverflow.com when there are new messages for you. It could sit there until you dismiss it or act on it. The problem with a modal is that it interrupts my flow and makes me feel like I must do something about it now.

whpalmer4

2010-07-09, 01:11 PM

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. :-)

Wait, WHAT? Did you just say that OmniFocus is being changed so that it will automatically drop the unsynced client and force me to lose any local changes on it without even asking me?!? How is that possibly an improvement?!? NO NO NO NO NO NO NO!!!!! DO NOT DESTROY DATA!!! I'd rather have the secret setting to defer the nag screen than have my data automatically destroyed for me. I have five instances of OmniFocus going between iPhone, iPad, and two computers. I simply cannot always remember to start something up every few weeks just to make sure stale changes get synced out.. this does not imply that I don't care about those changes, though. User data should never be put in such haphazard jeopardy!

Rereading this thread prior to adding to it, I'm struck by some of the conflicting desires. Wealthychef is unhappy that the design of the sync mechanism preserves the history until all devices are on the same page (the alternative being that changes from infrequently synced could be lost, possibly without warning). Xeri is unhappy that the sync mechanism is being updated to put infrequently synced devices out to pasture (without losing their data, though some effort is required to recover it). Everyone wants fast, reliable syncs.

I've spent a bit of time ignoring one of my devices while intensively using the others recently, and my experience is that if you do this, as some seem determined to do, it essentially guarantees that you will not only slow down the devices you use frequently, but also when you do finally go to use the neglected device, it will cause a big database compaction to occur (all the devices finally being on the same page), and you'll have to twiddle your thumbs while the newly compacted database is written back to the server, possibly over a very slow cellular connection.

Maybe I just don't understand a workflow where it's more important to have a rather stale copy of your data ready and waiting to be used immediately (but rarely) than having speedy results on the usual case.

Xeri

2010-07-09, 11:42 PM

Again, whpalmer, you fail to understand my concern. I paid for this software (and the iPhone app, and the inevitable iPad app, when it arrives) so that I can put my data into it in substantial part so that I do not forget it. Throwing away any part of my data without giving me any recourse to avoid the operation completely defeats that purpose and undermines the apparent utility of the entire software family for me. Giving me the "option" to manually re-enter my data again after I had already entered it once makes me question why I expended the effort of putting the data into the software in the first place if it's going to be at risk of arbitrary discard. Why did I bother spending the time to enter that data in the first place if I'm always going to be at risk of having to manually reconcile it again? There haven't even been any details provided here of how reconciling such an event would work in the first place, which leaves me even more concerned.

Given all of this, I've already suggested that as an alternative to reverting this behavior, how about providing an opt-out for the people who understand the implications and understand that letting the databases drift too far out-of-sync will have performance implications? That way you can satisfy those who don't understand why their syncs are getting slower but not scare off those who take data integrity very seriously.

Xeri

2010-09-10, 08:09 AM

I see the new release has dropped: so is there any way to turn this behavior off?

Ken Case

2010-09-10, 09:28 AM

I see the new release has dropped: so is there any way to turn this behavior off?

The "dead" client age timeout is controlled by the SyncClientDeadAge hidden default. Its default value is three weeks (1814400 seconds), but you could change it to one quarter (13 weeks, 7862400 seconds) with this Terminal command:

defaults write com.omnigroup.OmniFocus SyncClientDeadAge -float 7862400

However, please note that you'll need to change this independently on every syncing device. (We can't easily sync the setting, because it's used to determine which transactions we pay attention to while syncing in the first place.)

The best-of-both-worlds way I'd like to solve stale clients going forward is to make it easy to merge and synchronize databases from unregistered clients, so we can merge changes from them without having to keep tracking every change which has happened while they were unsynchronized. (That would also be useful for initial synchronizations as well, such as when someone first sets up their iPhone and iPad independently and later decides they'd like to sync them together.)

Xeri

2010-09-12, 11:26 AM

I'm assuming that this mechanism is not in the mobile clients, then? (Since there's no way to do a defaults write on those platforms it would be a problem if it was...)

Oh and is there a limit on this interval? Could I set it to something like 30 years if I wanted to?

Ken Case

2010-09-12, 03:46 PM

I'm assuming that this mechanism is not in the mobile clients, then? (Since there's no way to do a defaults write on those platforms it would be a problem if it was...)

The equivalent way to set that default on the iOS apps is to open a URL of the form x-omnifocus-debug:set-default:SyncClientDeadAge:7862400. (Unfortunately, vBulletin doesn't allow x-omnifocus-debug links, or I'd just make the above a link.)

Oh and is there a limit on this interval? Could I set it to something like 30 years if I wanted to?

The software will ignore the interval if it's zero or negative, but there's no maximum other than the maximum size of a floating point number. 30 years would be just fine.