FeedSync Design Principles
There's been a good discussion for the past couple of days on the atom-syntax list about sync, mostly focused on tombstones.
It's useful to know that our primary design point for FeedSync, as Joe Cheng points out, is around "mesh sync". That is, if you have a collection of resources that you can represent as a feed, FeedSync is designed to reliably synchronize that resource collection across any number of endpoints in any conceivable network topology. As the spec says,
The extensions described in the FeedSync specification enable feed readers and publishers to generate and process incoming item changes in a manner that enables consistency to be achieved.
The "achieving consistency" part means that you can be sure that if you implement the spec correctly, all nodes in the mesh will converge on the same data.
Another main design point is that FeedSync is designed for synchronizing human-scale data. That is, things like contact information, calendar items, task lists, and so on. A couple of people have asked me whether you could implement something like SubEthaEdit with FeedSync. You could...but there are sure to be sync methods that are better for that kind of task. On the other hand, if the result of your SubEthaEdit-ing session is a collection of documents that you want to synchronize across multiple machines, then FeedSync is a great way to accomplish that.
One of the cool things about FeedSync is that even though it is designed for two-way, multi-endpoint mesh sync, it is still a pretty Simple set of Extensions on top of Atom and RSS. That means that FeedSync is simple enough to be useful in much simpler scenarios, such as one-way publish-subscribe, or two-way client-server scenarios.
There were some comments (from James Holderness and James Snell, for example) that FeedSync is unnecessarily complex for a task like deleting blog spam from client aggregators. That might be the case; and I'm certainly an advocate of using the simplest solution that accomplishes the task. As I said above, FeedSync's primary design point is around broader scenarios than just blogs. But if you think about your blog as a collection of resources, and you want that resource synchronized across multiple endpoints, then FeedSync is worth a look.
