Quote:
Originally Posted by whpalmer4
The network stack being up doesn't necessarily mean you can do anything useful with it. Your laptop wakes, brings up the network stack, sends a network configuration changed event to any and all processes listening for one and they promptly try to do something. Too bad you've got a DSL connection that went idle while your laptop was asleep, and now the router has to bring that up (which can be pretty pokey, relatively speaking) before it can answer the DNS queries for the address of sync.omnigroup.com. Your initial sync attempt may well time out during that process.
|
No, my Internet connection is up. I have more than one device accessing it. Seriously, if I wake my laptop, go through the screen saver, by the time I can get OmniFocus displayed on the screen, it has already failed. The time is less than 10 seconds. No other applications on my machine that I've observed give up and go into a "failed" state this quickly.
Quote:
|
Hmm, what other modern sync systems sync OmniFocus databases? What seems to be a more efficient sync system may just be one that has a simpler problem to solve!
|
They don't sync my OmniFocus database, but the Things "cloud" sync and The Hit Lists's sync both have no problems with network wake state, under the exact same state of conditions.
Quote:
|
Arguably, a failure that looks like it might be due to the network being offline (failing to look up the address of the sync host, for example) ought to cause another sync attempt to be scheduled shortly thereafter, perhaps using the TimeFromFirstEditToSync setting (which controls how long it is between you making a change and OmniFocus attempting to sync it to the server, default value being 60 seconds). Because a network configuration change notice doesn't tell you that you've got end-to-end connectivity to the sync server, just that you're now connected to some network and can start bleating packets out into the ether, this is a desirable change IMO even if OmniFocus starts using network configuration change notifications.
|
Sure. Try when you get the 'network state changed' notification. If that fails, try again at 5, 10, 30, and 60 seconds (or whatever your "back off" algorithm is) and then fail.
Quote:
|
Support can't do anything for you except offer workarounds if engineering management declines to address the issue.
|
Sure, but this largely semantics. Saying "I understand" and then having engineering de-prioritize the issue so it's not fixed in 3+ years is poor support (not on the part of the support staff, but really on the part of the company to "support" its products by fixing frustrating bugs). Any workarounds to change sync times stink, unless I want to change the interval from 60 minutes to 1 minute to address this (which would cause unnecessary server load… if every customer of the Omni Sync Server did this, it would be a nice DDos and probably require them to build out 20 times the current server infrastructure.