Simple Sharing Extensions (SSE)

What is the Simple Sharing Extensions specification?

Simple Sharing Extensions (SSE) is a specification that extends RSS from unidirectional to bidirectional information flows.

SSE defines the minimum extensions necessary to enable loosely cooperating applications to use RSS as the basis for item sharing-that is, the bidirectional, asynchronous replication of new and changed items among two or more cross-subscribed feeds.

For example, SSE could be used to share your work calendar with your spouse. If your calendar were published to an SSE feed, changes to your work calendar could be replicated to your spouse’s calendar, and vice versa. As a result, your spouse could see your work schedule and add new appointments, such as a parent-teacher meeting at the school, or a doctor’s appointment.

SSE allows you to replicate any set of independent items (for example, calendar entries, lists of contacts, list of favorites, blogrolls) using simple RSS semantics. If you can publish your data as an RSS feed, the simple addition of SSE will allow you to replicate your data to any other application that implements the SSE specification.

SSE can also be used to extend other formats such as OPML.

What kinds of scenarios does SSE enable?

Just as RSS enables the aggregation of information from a variety of data sources, SSE enables the replication of information across a variety of data sources. Data sources that implement SSE will be able to exchange data with any other data source that also implements SSE.

From the user’s perspective, this means that you will be able to share your data (such as calendar appointments, contact lists, and favorites) across all of your devices and with anyone else that you choose, regardless of infrastructure or organization.

SSE is particularly useful for scenarios in which there are multiple masters and/or asynchronous updates. For example, SSE could be used to share your work calendar with your spouse-either of you could enter new appointments, even if not currently connected. Similarly, SSE could be used to replicate a set of calendar entries among a group of people, each working in a different company and using different infrastructure.

When should I use SSE as opposed to some other synchronization technology?

SSE is ideal for replicating data that can be published in an RSS feed. That includes lists of items such as calendar appointments, contacts, favorites, and news items. In addition, SSE is ideal for bidirectional, asynchronous replication, particularly for scenarios where multiple people can edit or create entries.

Like RSS, SSE was designed with simplicity in mind, and developers will find that implementing SSE replication is easy, especially for an application that already supports RSS.

Are there any license restrictions to using SSE?

Microsoft has released the Simple Sharing Extensions specification under the Creative Commons license, the same license that covers the RSS 2.0 specification. This license lets others remix, tweak, and build upon the specification even for commercial reasons, as long as they credit Microsoft and license changed specifications under the same terms. Read this for more information about the Creative Commons license.

How does this relate to other RSS initiatives within Microsoft?

SSE is distinct from other work within Microsoft related to RSS, such as the support for RSS within Vista, the next version of the Microsoft® Windows® operating system, and Simple List Extensions to RSS, which can be used to enable Web sites to publish lists, such as photo albums or music playlists. While distinct from other RSS-related projects within Microsoft, SSE is another example of Microsoft’s desire to make it easy for users to discover, read, and subscribe to RSS feeds, as well as enable developers to deliver powerful applications that can act on behalf of the user. With SSE, users can use RSS for bidirectional replication, not just unidirectional publish and subscribe.

What does it mean for the SSE specification to be at version 0.9?

The SSE specification published here is a draft specification. We are seeking feedback on how this draft SSE extension to RSS 2.0 and OPML can be improved. As with the Simple List Extensions (previously announced by Microsoft), we will incorporate feedback from the community and produce a 1.0 version. Please check the Microsoft Team RSS Blog for discussion on the SSE spec, or to send feedback or questions directly to the team, contact teamrss@microsoft.com.

Technology

How does SSE work?

SSE defines new XML elements that add replication information to items in an RSS feed. These new elements enable SSE applications to implement bidirectional RSS. In other words, two endpoints can mutually publish and subscribe to each other’s RSS feed. When changes are made in one endpoint, they are propagated to the other and vice versa.

The new XML elements described in SSE enable feed readers and publishers to generate and process incoming item changes in a manner that enables consistency to be achieved. In order to accomplish this, SSE introduces concepts such as per-item change history (to manage item versions and update conflicts) and tombstones (to propagate deletions, and un-deletions).

What kinds of topologies are supported by SSE?

Any topology of feed interconnection is supported, from a hub-and-spoke to a star, to loops, to an arbitrary mesh. Item update propagation time or reliability might vary depending upon the topology, or the symmetry of feed update periods between cross-subscribed feeds, but the ultimate consistency of all feeds is assured. No „master feed“ is required; there is no „true state“ retained in a centralized manner.

How many endpoints can participate in SSE replication?

Any number of applications and devices can participate, representing any number of users. A single collection of items can be shared by two people or two thousand, each being a potential reader or writer.

Can endpoints make changes asynchronously?

As in standard RSS, feeds can be updated asynchronously. There is no requirement that changes be made online in order to assure consistency.

What protocols does SSE support?

The focus is on the data format; HTTP/HTTPS is not required as a transport protocol. As long as a publisher’s RSS files and their dependencies (such as enclosures) can be transported to subscriber (for example, through a store-and-forward relay), any protocol will work.

Is SSE secure?

SSE defines a set of XML elements to express replication information in RSS. SSE does not define a protocol or a means for communication. It is possible to transmit SSE information over any protocol, including secure ones such as SSL, WS-Secure, etc.

Does SSE scale?

Simple Sharing Extensions are designed to extend RSS and as such scale to the same degree as RSS.

Can SSE be used with Atom?

This version of SSE does not define extensions to Atom. Nevertheless, in principle these extensions could be used in Atom.

How does SSE extend OPML?

The Outline Processor Markup Language (OPML) is ideal for representing hierarchical collections of independent items. For example, OPML can be used to store categorized music playlists or categorized blogrolls. SSE extends OPML to enable bidirectional replication of OPML files.

Implementation

Where can I find sample code?

As this is still a draft specification, sample code is not currently available. We will publish sample code around the time when we finalize the 1.0 version of the specification.

How often should I poll for changes?

As in any polling system, the average latency that a user will experience to get a notification will be one-half of the polling interval. For some of the examples here, such as calendar replication, a polling interval of minutes is appropriate. For other use-cases, such as replicating a contact list or (perhaps) favorites list, a polling interval of hours is sufficient.

The publishers may use the window attribute in the sx:sharing element to express the size of the window of change history kept by the publisher. Subscribers should poll at least this frequently.

How much item history should I keep?

Publishers should keep as much item history as is practical. For most of the scenarios in which SSE is used (calendar replication, for example) we recommend that the publisher keep all history.

When should I purge deletion tombstones?

Deletion tombstones may be purged if they are older than the window of change history kept by the publisher.

Schreibe einen Kommentar

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s