Per-Item Data

[aaronpk]

It's clear that there is a need for the reader and server to store additional per-item data that is not part of the post itself. Things like:

• read/unread status
• whether the user has already taken certain actions on the item (already favorited or reposted it)
• whether there are any comments in the thread, how many there are, whether the user has commented
• starred/unstarred status
  • This is something many feed readers have copied from the old Google Reader. (Did it originate with Google Reader?) Starring items is a lot like bookmarking within the reader and often instructs the back-end not to remove a post from storage.
  • A star was used here in much the same way as browsers use it in their UI to denote bookmarks. The design influenced the name.
  • Readers known to implement starring in their API include Feedbin, NewsBlur and Feed Wrangler. Feedly uses a special global "saved" ID as an “[e]quivalent of starring articles”.

There are a few ways we could store the additional per-item data.

• Add new properties to the item object
  • may conflict with future Microformats vocabularies
• Create a single new property (e.g. "microsub") that contains all the additional data
  • avoids possible vocab conflicts except for the name of the one property
• Wrap the item in a new object which can contain these additional properties
  • makes accessing the post data an extra level deep, possibly awkward
  • won't conflict with Microformats vocabularies
• Prefix all new properties with "_"
  • avoids vocab conflicts since underscores are never used in vocab terms
  • is an indication that this property is not part of the post data

[aaronpk]

With the work in tracking read state, I've started implementing these additional properties by prefixing them with _. I felt like that was the least obtrusive way to include them while also making it obvious they are not part of the post vocabulary.

Additional brainstorming around other per-item data should be discussed in new issues.