Stateful OPML Extensions

At the moment, OPML is used (in the majority of cases) to store subscription lists. I’ve used it for exporting my feed list from Newsgator & importing it into Newshutch, and it was certainly useful for that because I now have all the feeds back, but something wasn’t quite right…I don’t care about all these entries that I’ve already read. And what happened to my flagged entries?

Why can’t OPML store what’s read/unread/flagged?

This would mean your “OPML” file would be stored in a central web-service of some kind. Instead of all the different aggregators storing your subscription list in their own format, they would point towards this service. You can still add/delete feeds and read/flag entries from your news aggregator, but in the background it would be writing all this to the central OPML service. That way, you can use a desktop client when you’ve got your own machine handy, or use any online service your heart desires. All you need to know is:<your unique identifier>

That’s all well and good, but there are a number of issues:

  • Who hosts the centralised OPML store?
  • What API should be used for accessing the store?
  • How should OPML be extended to support this?

I don’t really have any answers to the first two issues (other than “myself” and “a RESTful Rails API”), but for the last issue this is the format I’ve been running over in my head:

Stateful OPML Example
<outline title="Example" htmlurl="" xmlurl="">
  <state type="all-read-until" identifier="7a5fd97d6080bbcb7b1dbbd6dd4faf02" />
  <state type="read" identifier="4326a8b7354da223a9a3a2018729ebe1" />
  <state type="read" identifier="f969a261b12aaa0a7e27d2861a3b4cde" />

Firstly, the identifier would just be a hash of the title & date of publish. So long as it’s unique, fairly short, and reproducible it doesn’t really matter.

I’m sure you could have many different state types, but in my few minutes of thinking about it these are probably the most useful in terms of minimising the size of an exported OPML file. For a feed with 5 entries, the number of state nodes will look something like this:

  • 0 if nothing read
  • 1 if everything read
  • (n-1) max if you’ve read random entries

The number of nodes could be minimised with more complex state descriptions, but it would be nice to keep it simple.

This is just an idea I’ve had kicking around in my head for a while. Does anyone think it has any legs? Could all the different companies providing aggregation services play nice and agree to a standard of some kind?

…perhaps more importantly, would you find this useful?