Simple Sharing Extensions for RSS and OPML
It’s nice to connect. I’m Jack Ozzie, development manager for Ray Ozzie’s concept development group. Besides being brothers, Ray and I have worked together for several years now developing and shipping software products with some amazingly talented development teams. I joined Ray’s dev team at Iris Associates in 1987, contributing to the development of Lotus Notes. In 1997, I moved on with him as co-founder of Groove Networks. After Microsoft acquired Groove Networks last April, I transitioned to Ray’s CTO staff, running a small development team here in Redmond.
As Ray mentioned in his blog posting on Nov 20, my team has been working with various Microsoft product groups and collaborating with Dave Winer, building proof-of-concept prototypes around the Simple Sharing Extensions for RSS, and refining the spec in the process. One of the key members of our team who helped to advance the spec and get it to the point where we were comfortable publishing the draft is George Moromisato. George is another member of the Iris/Groove alumni; his knowledge of Notes replication and Groove synchronization are incredibly valuable to this initiative. Since Dave and Ray’s initial blog postings, I’ve been very encouraged by the development community’s initial reaction; it has definitely generated some interesting conversation, as evidenced by this post. Our team is looking forward to working with the community to complete the SSE spec so we can all get to work building this into our products and services, enabling new seamless sharing experiences for customers, and creating new opportunities for partners. Here’s some additional context for why we are so excited about the potential for SSE.
Why SSE?
The marketing wonks told us to follow the “Rule of Threes.” So we’ve come up with three words – all beginning in S - to answer the “Why?” question.
Simple. 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. SSE defines the minimum extensions necessary to enable loosely cooperating applications to use RSS as the basis for item sharing. We view this as a means by which disparate products can work together without hard-coded dependencies. We also wanted to make it simple enough to encourage widespread adoption. We hope you’ll take the time to review our draft specification and give us your feedback on whether we accomplished our goal in relation to simplicity.
Seamless. The SSE draft specification is just one initiative in our overall objective to provide “seamless experiences” for our customers as they migrate back-and-forth throughout the day from work persona, to family persona, to community volunteer persona, etc. SSE allows you to replicate any set of independent items (calendar entries, lists of contacts, lists of favorites, blogrolls, etc.) using simple RSS semantics. It also supports asynchronous replication of new and changed items, meaning it can work even when you’re offline. It also works across firewalls, and across different company infrastructures. This is but one initiative in our overall plan to provide our customers with the kind of “just works” experiences they’ve come to expect in other aspects of their lives.
Sharing. The “so what?” of SSE is that it extends RSS and OPML from unidirectional to bidirectional information flows. Let’s just focus on calendaring for now. There are three layers of calendar today: 1) Private/personal, 2) A group, and 3) A public calendar for events and schedules to which individuals or groups can subscribe. The ability to subscribe to a public event calendar is certainly useful, and a step forward. But it’s still just a one-way exchange of data. We believe SSE addresses a larger problem that our customers have today. For example, why do your work and family calendars have to be separate? With SSE you could share your work calendar with your spouse. If your calendar were published as 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 calendar and add new appointments, such as a parent-teacher meeting, or a doctor’s appointment. Moreover, 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.
Answers to the other two most important questions: “What?” and “How?” are addressed in the draft spec and FAQ.
We would love to get your feedback on this spec. We don’t have a definitive deadline, but we look forward to getting your ideas and comments so we can incorporate them into a 1.0 specification that will be published in the coming months.
In addition to this blog, where you can provide comments, we’ve set up a mailing list at feed-tech@discuss.microsoft.com for discussion of the SSE spec (as well as the SLX spec and any other RSS topic of interest to subscribers). Please join us if you want to contribute to the SSE spec.The archive of the mailing list discussion will be available for those who want to follow without subscribing. Major changes to the spec or major issues will be posted for discussion here on the blog as well.
To subscribe to the list: Send email to: listserv@discuss.microsoft.com with the message body “subscribe feed-tech” or use the web-based subscription form.
-Jack