Really Simple Sharing
One of the great things about once again having an active blog is that it enables me to engage in discussion about concepts I’m excited about, and that I’m working on, before they’re fully-baked and while they could benefit from others’ involvement. The first such thing I’d like to introduce here is something we’ve been calling SSE.
By way of background: for a few years now, I’ve grown to be passionate about the fact that people (and organizations) are choosing products & services relevant to their needs that have compelling experiences that “just work”. Such is the basis for all of my current work related to service-enabled software.
For years, as many of you, my work life has involved significant travel. As significant bi-coastal coordination has now entered into the mix, things have gotten even more complicated for me, for my wife, for my assistant and hers. In order to stay on the same page, each of us has the need for (limited) visibility into aspects of each others’ calendars and schedules. Each of us has a mix of private, shared, and public events and meetings that we’re tracking.
Some of these we edit privately and publish to others. (This itself has posed significant challenges – particularly sharing partial information from confidential calendars.) The most challenging calendars we deal with are those that are “shared”, such as the family calendar my wife and I jointly maintain, or the calendars we share with outside groups – such as the meeting calendars of volunteer organizations.
It’s tough because we use a mix of different email/calendaring systems – corporate as well as non-corporate, web-based as well as client-based. And to each of us it makes sense to want to edit the calendar in our own PIM application of choice where we do all our calendaring and scheduling work – not within calendaring systems on other various websites.
And the same goes for contact lists. In our case, each of us has a mix of private, shared, and public ‘address books’ or ‘contact lists’ that we’re managing. At work I deal with contacts in my enterprise directory as well as my own private contact list. But I share two completely different contact lists with my wife – one that is our “home rolodex’ with plumbers, doctors and the like, and one that is our “family rolodex” with friends & family. And I know she has other contact lists she shares privately with members of groups she’s working with.
As an industry, we have simply not designed our calendaring and directory software and services for this “mesh” model. The websites, services and servers we build seem to all want to be the “owner” and “publisher”; it’s really inconsistent with the model that made email so successful, and the loosely-coupled nature of the web.
Shortly after I started at Microsoft, I had the opportunity to meet with the people behind Exchange, Outlook, MSN, Windows Mobile, Messenger, Communicator, and more. We brainstormed about this “meshed world” and how we might best serve it - a world where each of these products and others’ products could both manage these objects and synchronize each others’ changes. We thought about how we might prototype such a thing as rapidly as possible – to get the underpinnings of data synchronization working so that we could spend time working on the user experience aspects of the problem – a much better place to spend time than doing plumbing.
There are many great item synchronization mechanisms out there (and at Microsoft), but we decided we’d never get short term network effects among products if we selected something complicated – even if it were powerful. What we really longed for was “the RSS of synchronization” … something simple that would catch on very quickly.
Using RSS itself as-is for synchronization wasn’t really an option. That is, RSS is primarily about syndication - unidirectional publishing - while in order to accomplish the “mesh” sharing scenarios, we’d need bi-directional (actually, multi-directional) synchronization of items. But RSS is compelling because of the power inherent in its simplicity.
This got me to thinking about simplicity. Notes had just about the simplest possible replication mechanism imaginable. After all, we built it at Iris in 1985 for use on a 6Mhz 286-based IBM PC/AT with incredibly slow-seeking 20MB drives. We were struggling with LIM EMS trying to make effective use of more than 1MB of memory. Everything about the design was about implementation simplicity and efficiency. So if simple is the goal, why not just adapt the Notes replication algorithm to this need? Notes “notefiles” could be analogous to RSS “feeds”; and Notes “notes” could be analogous to RSS “items”; and Notes “items” could be analogous to XML “elements”.
Notefiles replicate by using a very simple mechanism based on GUID assignment, with clocks and tie-breakers to detect and deterministically propagate modifications. Something like this could easily be represented in XML. Notefiles replicate with one another in a decentralized, masterless manner; feeds could be “cross-subscribed” in a similar manner. There’s no magic to it once you know specifically what you’re trying to accomplish, but it certainly helped to have an existence proof.
And so we created an RSS extension that we refer to as Simple Sharing Extensions or SSE. In just a few weeks time, several Microsoft product groups and my own ‘concept development group’ built prototypes and demos, and found that it works and interoperates quite nicely.
We’re pretty excited about the extension - well beyond the uses that catalyzed its creation. It’s designed in such a way that the minimum implementation is incredibly easy, and so that higher-level capabilities such as conflict handling can be implemented in those applications that want to do such things.
Early on, after we had a prototype going, I met with Dave to tell him about it and perhaps get him involved. Immediately at our first meeting he spotted its potential to solve something else he had been thinking about – replicating changes among OPML lists or outlines being managed within different services or by different people. He challenged us to see if the same SSE mechanisms could be applied to OPML. As it turned out, only minor changes were required. In essence, by connecting these dots between what we’d done to extend RSS and his vision for OPML, Dave’s catalyzing a new form of decentralized collaborative outlining.
At this point, various groups at Microsoft have begun to further develop their early prototypes to see what we can learn, and to ensure that the spec is sufficient. There’s nothing to announce right now in terms of which products will support the spec, when, and for what purpose, but people are experimenting with it and are intrigued. It’s time to bring the spec to you, so that you can do the same.
We’ve numbered the draft specification 0.9 because we have a good degree of confidence in its usefulness based on the prototyping that we’ve done thus far, but it’s certainly not a 1.0 and I would certainly caution against building anything ‘production’ on it quite yet.
Here’s the draft spec for SSE, and here’s a FAQ that we put together. A forum where we can talk about it amongst implementers will be forthcoming.
(Props for making the spec and early prototypes actually happen go out to the individuals in many product groups - you know who you are - who were motivated enough to want to enable this scenario for users. And to Dave for extending it to OPML. It’s been fun working with all of you, and impressive how rapidly this could happen.)
One other important point: We’re releasing the SSE specification under a Creative Commons license – Attribution-ShareAlike. I’m very pleased that Microsoft is supporting the Creative Commons approach; you can see more about this at in the licensing section at the end of the spec.
Enjoy.
