Synchronization (was “Other bad ideas…”)
Synchronization (was “Other bad ideas…”)
I want a cross-platform data sync system that apps can plug in to, to carry your data from machine to machine as you go throughout your day. Most people with computers actually have two computers – the one at home and the one at work. I’m one of those people (also I have a laptop). I want to be able to take it with me.
I suspect the Mozilla Foundation is best poised to do this because:
- They can integrate Mozilla, Firefox, Camino, Thunderbird and Sunbird, and let other people deal with other software.
- The Mozilla Foundation is insulated from the lack of business model.
So here’s a hackish (but possibly workable) proposal: implement such a system as a layer on top of Subversion.
Subversion contains all the logic and semantics needed for conflict resolution and merging. The simplest implementation would be:
- Put all sync-able data in text files stored in well known locations.
- Sync those to a repository of your choice (e.g. one of your machines, a server, a paid service).
- Create a UI (or one per app) to present conflicts to the user and let them decide how to handle the conflicts.
- Index the (versioned) text documents for searching. Do not version the index, but update it locally as version changes come in over the wire.
This has its upsides:
- Most of the logic is already there – all the new work is in UI (with the exception of the Windows version of the Palm Desktop, every synchronization and versioning system I’ve seen that isn’t a source code control system is insufficiently reliable).
- Most of the code is already there.
- The code is open source.
- Subversion offers a number of different ways to access the repository, which would let people sync across their own machines or via a hosted server somewhere on the net.
- The sync history is a permanent backup – you can revert to any earlier version of the world that had been synced.
It also has its downsides:
- It’s somewhat heavyweight.
- It’s overkill.
- It will take up a lot of space, especially as the backup/history grows.
- The permanent backup is permanent unless you wipe the whole thing – you cannot delete individual historical revisions. Thich may conflict with data retention policies.
I admit this is a bit of a hack, but it’s worth asking why people keep reinventing wheels.
One person pointed out that Subversion doesn’t take that much space (either for the repository or the local data). This is probably true in any real sense (the average user’s repository will be smaller than one mp3).
As a couple people pointed out, Apple has this in .Mac sync. However, Apple’s solution some serious downsides:
- It costs $100 per year.
- It’s Mac only – if you’re one of the rare 98% of people who use a Windows machine at work you’re out of luck.
- Bookmark sync works with Safari only – even if you use a Mac, you’re stuck on the slowest, most feature-poor browser still actively supported on the Mac.
- Steve’s servers – you’re dependent on the servers Apple maintains, and can’t put the data on your own machines (think of the security concerns for corporations).
- It doesn’t work – at least in any meaningful sense. The .Mac support forums are constantly full of threads about how .Mac sync is currently broken.
Someone rightly pointed out that svn takes care of syncing text files and well-known-data, but doesn’t deal with things like merging Word docs. I can live with that, but I’m guessing it’s something people could add if the sync architecture allowed for plugins for different apps and data types (since svn would notify of conflicts). I think the right approach is to start with a limited but extensible set (e.g. the Mozilla apps), and worry about harder problems (e.g. MS Word docs) in the second phase and extensions.
A couple people suggested ways to shrink the history/backup. None of the suggestions so far are particularly pretty (see the Subversion FAQ for more on this).
And yes, I’ve now seen the SEE/RSS proposal.