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. [Russell Beattie Notebook]