<entry> <id>http://id.dehora.net/entry/2008/07/12/ea18ed947f5ba3e06ff02528f7e6b150</id> <title>Free as in electricity</title> <updated>2008-07-12T15:59:34Z</updated> <author> <name>Bill de hÓra</name> </author> <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/" rel="alternate"></link> <content type="html"><p> ... </p> </content> </entry>
Some observations:
The Friendfeed updated value happened a few minutes before mine did. It doesn't seem to be a multiple of anything, so let's assume it's a clock skew. What's interesting there is that Friendfeed's Entry could show up after mine in an aggregated feed.
The Friendfeed Entry doesn't have an author element. The enclosing feed did have one, and the author is "Friendfeed", which means the author of that Entry is "Friendfeed", not me. I guess that makes sense. Or maybe it doesn't.
Friendfeed added their own id. It's a Tag URI that has a uuid embedded. This makes me think their backend is decentralised or at least has the potential to be. The date part of the tag appears to be hardcoded to 2007.
Friendfeed munged the original title with a suffix. They added a type of text/html as well. I wonder if that was derived or assumed. And I wonder what would happen if the source type was set to say, xhtml. In any case what's nice about my use of Atom here is that Atom Text constructs have well-defined escaping rules - unlike RSS2.0, there's no need to second guess the upstream provider (unless it's borken).
Friendfeed have copied the link@rel=alternate across. They've added a type of text/html. Again I wonder if that was derived or assumed. It would be interesting to have a JSON alternate.
Friendfeed have written out their own content. That's fine; what's notable is not providing a summary of the original. Or maybe that's because I don't server summaries, just full content.
Friendfeed use xml:base. It would be interesting to see if what would happen if relative URLs were in the source title, which seems to have been copied into their content.
Friendfeed are not proxying or rewriting upstream links. A naive system would do something like that for tracking reasons, and eventually melt down under load. The only interesting redirect walling they perform is to route the "link to this entry option" on the site back to their permalink and not mine. The slug for the permalink is the same as the uuid in the tag URI.
But for a syndication wonk, by far the most interesting thing is that Friendfeed aren't using the Atom source element. The feed could have looked like this:
Not many people seem to use Atom source. It can contain the whole original entry, but the most useful parts to pass along are the id and the updated elements. Why? Well, aggregators and clients can immediately pick those out, tell you if you've smelt what the Friendfeed is cooking and mark it as read. In this particular case the fact that Friendfeed's outer updated date is ahead of the source might confuse some code, depending on the implementation logic. Possibly they should consider treating updated as an offset to the original Entry timestamp. It might not be precise relative to a particular server/system but globally it will be more accurate and the partial ordering would be preserved. You could also put the source author in there as well ;)
Previous Topic
