This blog can't be viewed on LiveJournal. Instead see

Moving the Goalposts

28th Jan 2009

In the few weeks since I published the first drafts of AtomActivity, ActivitySchema and friends several things have come about:

  • FriendFeed is collapsing multiple photo-related activities together into a single entry in its activity feeds.
  • FriendFeed is using MediaRSS-in-Atom to publish Flickr photos in its activity feeds.

The former opposes a decision made in the name of simplicity at the last activity streams meetup to go with one activity per entry. However, since the spec is being lead by implementations rather than the other way around, I'm planning to reverse this decision and go for a slightly less constrained model where an activity entry can have multiple objects, as long as the verb, actor, context and other activity properties are the same for each. Doing any further coalescing (similar activities by multiple actors, for example) is the job of the UI layer of the aggregator and should not be reflected in feeds. The next iteration of the spec will contain a section with requirements specifically targetting activity re-publishers and aggregators describing what their feeds should look like.

The latter further erodes the argument that we can do AtomActivity because MediaRSS-in-Atom is not yet widely deployed. However, it's still not a slam-dunk for MediaRSS-in-Atom because the way FriendFeed is publishing these elements (as direct children of the activity's atom:entry element) puts them outside the purview of AtomActivity, which expressly ignores everything except the publication date and the activity-specific elements in an activity entry, under the assumption that the content there is intended for non-activity feed readers... therefore (and this will be written explicitly in the next draft of the spec) activity feed publishers can put anything they like in there that will make non-activity feed readers behave in the desired way, and activity-aware readers should ignore it and use the activity information.

Folks who were keen on AtomMedia as an alternative to MediaRSS-in-Atom should take note, though, that the likelyhood of success of the former is getting weaker with each system that implements MediaRSS-in-Atom; I don't personally have time to work on AtomMedia at the same time as AtomActivity, so I'd love it if someone else would take over as author of the media spec.


TPCThread 6a010535617444970b01053614336e970c