Maybe this synch mechanism won't suck?
I've decided to leave the BlogLines and Newsgator synchromization APIs alone - the former is incomplete, and the latter assumes that the definitive copy of the data is on the server side - they use their own ID for each item, and expect you to synch with that. Thanks, but it sounds like that's more trouble than it's worth.
So it sounds interesting to me that Google is jumping into the fray:
Google plans to offer a feed reader API to allow third-party developers to build new views of feed data on top of Google's backend. The new APIs will include synchronization, feed-level and item-level tagging, per-item read and unread status, as well as rich media enclosure and metadata handling. Google Reader PM Jason Shellen and engineer Chris Wetherell both confirmed Google's plans after I posted my reverse-engineering analysis of the Google Reader backend.
With any luck, it won't suck :)
Comments
permalink???
[ Troy Brumley] December 28, 2005 9:22:43.440
Comment by Troy Brumley
Are urls suitable for synching?
Now we see the complexity
[ James Robertson] December 28, 2005 11:05:56.384
Comment by James Robertson
In theory, yes. In practice, the problem is this - in RSS, the <link> item is not guaranteed to be unique. It's not even required to be a link back to the item being looked at - it can be a link to a related item. So, say I write about Sony DRM, and then I write about it again. The <link> element could point to some other page in both cases.
Now, RSS can have a GUID element, which is supposed to be unique. But it doesn't have to be an url (it's not for the feeds here, for instance). Atom cleans a lot of those ambiguities up, but there's a ton of RSS out there.