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.
More on those later...
