Quote:
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!