From Simple Sharing Extensions to FeedSync

It’s been a couple of years since Ray Ozzie kicked off the Simple Sharing Extensions (SSE) initiative on his blog. It’s not so easy, by the way, to know exactly how many years it’s been. If you search for sse ray ozzie you’ll land on this page which is dated Nov 20, but no year is mentioned. I had to browse around in the archive to remind myself it was November 2005. Blogging platforms — and I’m not singling out Live Spaces here, they’re all in the same boat — aren’t good places for documents that turn out to have historical significance. Of course you never know what will turn out to be significant. That’s why I’ve been evangelizing the idea of a hosted lifebits service that will keep our stuff intact, and available for reliable long-term citation. But, I digress.

SSE was updated this week, and renamed as FeedSync. Over on Channel 9 I published a podcast and a screencast (Silverlight, Flash) with Steven Lees, one of the folks working on FeedSync. The screencast walks through an example (available at CodePlex) in which two simple list-making applications, running on two different machines, synchronize the insertion and deletion of items. In this case they talk through a relay service, but that’s not required. FeedSync is agnostic to topology and transport, specifying only how to represent updates, deletions, and conflicts in RSS and Atom feeds, and how to process those events into a merged result.

The merge algorithm described in the spec isn’t something most of us are going to be able to bang out quickly and reliably, so I’ll be on the lookout for implentations that package up the logic. One of those is the Microsoft Sync Framework, which has just updated the Microsoft.Synchronization.Sse namespace to Microsoft.Synchronization.FeedSync. I haven’t found good examples for using it, so if you can point me to some I’d appreciate that. Similarly I’m curious to know about other implementations of the synchronization logic for other programming environments. Or, equally interesting, implementations delivered as cloud services.

Although FeedSync is capable of full-blown multi-master synchronization, there are all kinds of interesting uses, including simple one-way uses. Consider, for example, how RSS typically has no memory. Most blogs publish items into a rolling window. If you subscribe after items have scrolled out of view, you can’t syndicate them. A FeedSync implementation could enable you synchronize a whole feed when you first subscribe, then update items moving forward. It could also enable the feed provider to delete items, which you might not want if the items are blog postings, but would want if they’re calendar items representing cancelled events.

RSS took off in part because it was human-readable and -writeable. To this day, you can get away with doing simple things “by hand”. With FeedSync, the RSS and Atom formats are still pretty easy to read and write. But nobody is going to do the rule-governed transformations by hand. For that we’ll need an ecosystem of libraries and services. I hope they’ll emerge because FeedSync is an extremely general mechanism that could be applied in all sorts of useful ways.