Microsoft SSE Thoughts
Everyone knows Ray Ozzie is my hero right? I spent the first several years of my professional career as a Lotus Notes developer, and even worked for Lotus itself for a brief stint in 1996, so you can imagine what an Ozzie disciple I am. I even was able to pay fealty to him in person back in 2004. I must say it pains me to see him working for a company like Microsoft, but that really doesn't lessen my respect for him in any way. Besides, he's been working with those guys for a long time now - we all saw the move to Microsoft as an inevitability way back in 2002 when Microsoft invested in Groove.net, right? So I've had a while to get used to the idea.
Regardless of where Ray is working now, it's nice to see in his post today that his Notes and Groove experience isn't far from his mind, and its incredibly exciting to me that he's now applying that work to RSS. As I've written many times before on this blog Everything New is Notes Again: In one way or another many of the principles of communication, synchronization and security that we're seeing in Web 2.0 all harken back to functionality that was available in Lotus Notes over a decade ago. (Ray's explanation today of how RSS tags correspond exactly to their Notes equivalent concepts showed this perfectly, if you ask me.)
So now I'm trying to grok the specifics of how the Simple Sharing Extensions laid on top of RSS are supposed to work. Here's some thoughts about the spec:
I like the idea of the simplest thing that could possibly work for synchronization, but the beginning stuff in the spec could be explained a bit better. Maybe exchanging the word "endpoint" for something clearer like "website" might help my mind? Honestly, the criss-cross subscription and aggregation stuff in section 1.3 is confusing on first read. I think I understand it, I just don't think it's explained well. I do think it's interesting how they're definining a time frame for the channel. This has been sort of ad-hoc up until now, where you get the last say 10 items in a feed, and that's all the info you get about the updates. Then the aggregator is forced to compare item by item until it finds something new or changed. If you were gone a week and more than 10 items have changed, then your aggregator will have no clue about them. With this system, you'll see there'll be a timeframe where you don't have information.
The item level sync stuff is great - with the history, deletion and conflict flags, and rules on how to resolve problems. Perfect! But isn't the sync id attribute duplicating the GUID tag of the item itself? What happens if they don't match up, or rather, what happens if they matched up at one point, and then later on change? I guess this would be considered a change, and be recorded as such, but it seems at that point there's a break-down in what an item is supposed to represent. Regardless, this system is essentially creating a system for keeping track of field-level changes, and that's pretty cool (and powerful).
But of course, RSS Items only have a few fields with real data: pubdate, link, title and description. Maybe a few more depending on which feed spec you use. In Ray's post, he talked about syncing things like contact lists and calendaring info. The SSE just manages the syncing itself - there's no place for the data to sit besides what's in RSS already. Where does this other stuff fit? In plain text in the description field? No way. Either he's talking about using this system with a bunch of different namespaces generated from various applications, or the next step must be an arbitrary field-data namespace for this sort of info.
This is what's being done already over in Mountain View... Remember the Google Base RSS Extensions spec from the other day? Their system allowed a variety of arbitrary fields to be embedded into an item. Adding in SSE namespace could then in theory allow *any* data contained in an item can be kept in sync. Pretty cool, hey? Sort of a universal data communication spec: Anything that any database can spit out, you can keep track of it, synchronize, and manage changes. Very, very cool. Now, I don't really like Google's implementation of the Base extensions. All those specific tag names like "course_name" and "hoa_number" are just ridiculous IMHO, and would be better off with a simple "field" tag with a type attribute and the actual data contained within the value of the tag.
I'm sure Ray and Microsoft realizes this as well. Maybe they're just planning on using the SSE stuff with the huge variety of MS apps that generate XML namespaces already, like for playlists or whatever. But personally, I'd like to see them embrace a simple data formatting spec as well, so that arbitrary data (like dates, strings and numbers) could be embedded into an RSS Item and syndicated as well.
Cool stuff.
-Russ