Full Circle Associates

I don't pretend to totally understand this from a technological perspective, but I sure do from a user perspective. Despite the celebration of the power of personal publishing (blogs, podcasts, etc.) I'm not always wanting a one way stream. (But I am owing James Farmer a comment on this thing thing he writes about that sometimes worries me as too "me-centric." But that's too simplistic. And heck, I lost the place where this conversation was happening. How's that for not-so-meshed!) I want and need collaboration. Negotiation -- even of calendars!

In his post, Really Simple Sharing Ray shares his team's new idea, via his own personal example (useful for us protogeeks). I'm including a fairly large snippet because - well, because I need it for understanding, so maybe some of you will too!

"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.

I'm happy to see the open source note, so I included that part of the snippet.

Categories: SSE, RSS, RayOzzie, collaboration