Steven Lees : Simple Sharing Extensions

About a "by"

StevenLees — Mon, 03 Dec 2007 03:53:00 GMT

I was reviewing the spec comments that we received over the past few months on the SSE spec, and because there was a fair amount of feedback about the “by” attribute on sx:history, I’d like to explain where the spec ended up.

Just to refresh your memory: every time an item or entry in a feed is changed, the endpoint making the change needs to add an sx:history element to call out the changes. The element has three attributes: a sequence attribute (the change number), a when attribute (date/time for the change), and a by attribute (the endpoint that made the change).

For purposes of sync, the by attribute has to uniquely identify the participating “endpoint”. You can think of by as the “endpoint ID.” The real world entity that the endpoint stands for could be one of several different things depending on your implementation: it could represent a user; or a user on a device; or a process for a user on a device; or something even more specific. One important consideration in picking which one of those things is an endpoint is that the by attribute determines the granularity of conflict detection. Any time an update is made by the same endpoint (the same “by”), that update subsumes all previous updates from that endpoint.

For a practical example, consider the case where I’m syncing data from my laptop to my phone. I change entry A on my laptop; then later (but before I’ve had a chance to sync) I change entry A on my phone. When I sync, one of two things happens. If the by attribute on both my laptop and my phone is identical, then one of those changes is discarded, because as far as the algorithm is concerned, they’re from the exact same endpoint. If the by attribute is different on the two devices, then both changes are preserved. At some point I’ll get to view both changes and choose which one I want to keep; no data is lost.

There were some suggestions that the by attribute should be required or recommended to be a URI. The reason that might be interesting is to somehow identify the (human) author of the change, or at least provide a pointer to the author. That’s definitely a useful thing to do. In the end, though, we felt that such a recommendation would make it harder for implementers to craft useful and unique endpoint IDs for their application.

Our recommendation is to choose the by attribute based on your granularity of conflict detection. Use a different element such as atom:author in order to indicate the source of a change.

Thanks for the feedback (past and future), it’s much appreciated!

Simple Sharing Extensions spec updates

StevenLees — Sat, 28 Jul 2007 01:50:00 GMT

I've received some great feedback on the Simple Sharing Extensions spec that I posted on MSDN last month. I'm working on updating the spec based on all of the comments, so I'm posting the proposed spec changes to the FEED-TECH list. I'll be rolling them out in a handful of emails; here is a link to the first one, and here is a link to the full list archive.

Comments and feedback are definitely appreciated! The best way to respond is to join the list and post your comments there.

SSE implementation on CodePlex

StevenLees — Wed, 04 Jul 2007 03:37:46 GMT

Daniel Cazzulino has posted an SSE implementation on CodePlex: the Simple Sharing Extensions for .NET project. Cool! I'm looking forward to checking it out.

When to sync?

StevenLees — Wed, 13 Jun 2007 02:25:06 GMT

Now that we've posted the updated SSE spec to MSDN, one of the next things on my list is to discuss how SSE works. Before jumping in to examples, though, I wanted to address a more fundamental question: when does it make sense to use SSE?

In my last post, I paraphrased the overview section of the spec which describes the scope of SSE. Here's what the spec says:

The scope of Simple Sharing Extensions (SSE) is to define the minimum extensions necessary to enable loosely-cooperating applications to use XML-based container formats such as Atom and RSS as the basis for item sharing – that is, the bi-directional, asynchronous synchronization of new and changed items amongst two or more cross-subscribed feeds.

When you are thinking about practical uses for SSE, one of the most important parts of the description above is the word bi-directional. SSE is going to be most interesting scenarios where you have multiple writers to the same underlying data store.

Let's work with a real world example. The New York Times has a desktop reader for their content called Times Reader. The reader caches the last seven days of news content on your computer so that you can access it even when you're offline. Should they change their application so that they are using SSE to sync that news content between your device and their server?

Probably not. The NYT is the authoritative publisher for their news content; even if you wanted to update it, I'm guessing they wouldn't want you to. You might think, though, that it would still be useful to produce an SSE-enabled feed to help the Times Reader cache the news content on your local machine, even if it's a read-only cache. It certainly wouldn't hurt anything to produce an SSE feed in this case, but all you really need to reliably cache the content is a unique ID for each content item, and SSE requires a bit more metadata that the reader application probably wouldn't end up using.

There is an interesting use case for SSE in the Reader application, though. The Times Reader includes the crossword puzzle. The "data store" in this case is the one where your crossword puzzle solution is stored. Wouldn't it be sweet if you could start working on the puzzle in the morning from home, then pick it up again at work and add a few more answers, then work on it during the afternoon commute from your smartphone (I'll assume you're not driving...), and have your answers automagically sync to all of those devices? You can if they're all syncing the data through SSE. You could do this through a browser-based service, too, but that typically requires you to be connected to the server whenever you want to work on the crossword puzzle.

Unlike the news content publishing case, there are multiple writers in the crossword puzzle scenario...but so far they all happen to be your own devices (home computer, work computer, and phone). Where SSE is most useful is when there are multiple people as well as multiple devices writing to the same data store. Imagine that your niece on the East coast happens to really like crosswords, and wants to work on the same puzzle with you. SSE tells the reader application what to do in order to merge the two sets of puzzle answers (aka data items) together.

That's just one example; SSE is certainly useful for other kinds of information beyond crossword puzzle answers. In Ray Ozzie's original blog post introducing SSE, he envisioned using SSE for calendar and contact information. SSE is also interesting in other configurations, such as server-to-server, as well as the peer-to-peer configuration described in this post.

Spec update for Simple Sharing Extensions

StevenLees — Tue, 12 Jun 2007 02:04:00 GMT

It's been a while in the works, but I'm happy to announce that we've update the specification for Simple Sharing Extensions. There are some pretty significant changes to this edition, including:

We added an SSE binding to the Atom feed format.
We made several changes to the sync algorithm to improve accuracy and efficiency
We reorganized the spec to improve readability
We removed the OPML binding from the v1 edition of the spec.

I've also updated the FAQ doc to go with the current spec. There are HTML/Javascript based tutorials for both Atom and RSS as well.

For those who are new to the spec, the scope of Simple Sharing Extensions (SSE) is to define the minimum extensions necessary for loosely-coupled applications to use XML-based container formats like Atom and RSS feeds as a way to synchronize a set of items across a distributed mesh of endpoints. In slightly more plain English, that means that you can have a set of applications and services that are all sharing the same underlying data in a loosely coupled way.