Reading page RSS

From Dreamwidth Notes
Revision as of 05:11, 4 February 2009 by Rho (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Following discussion in IRC about whether an RSS version of the reading page is something we might want to offer:

Pros

  • It's something people have asked for before, and would be an extra way for people to interact with site content.
  • Could potentially be use full in cross-site integration.
  • If we have a proper RSS version of our reading page, we'll be able to do it right, as opposed to the custom style version that some people currently use on LJ.
  • In theory, serving RSS should be less bandwidth intensive than serving HTML.

Cons

  • Concerns about ownership of content and the owner retaining control.
  • Might encourage people to put their feeds with authas details on public, web-based feed readers.
  • If the security setting of an entry is made more restrictive, a version grabbed from the feed may persist longer than the author wished.
  • In practice, people having feed readers automatically polling the site every 30 seconds could lead to increased site load.

Possible implementations

Any one or more of the following could be used to try to minimise some of the potential problems.

  • Have the extent of entries showing up in reading page RSS feeds be settable in the same way that they are for entries in the recent entries RSS feed. That is, allow full entry, summary only, title only or (possibly) no entry showing up at all. This could be either based on the same option as for recent entries, or it could be possible to set the two individually.
  • Make it so the reading page RSS works only if authas information is provided. This would cut down on the potential for entries to end up splashed around the web with ambiguous or no authorship attached, but could increase the likelihood of people accidentally leaking their passwords/other people's entries where they shouldn't be.
  • Have a delay time between an entry first being written and the entry appearing on the feed. This could give time for any "oops" moments and quick editing of security before the entry appeared on feeds. It could also be used to limit the frequency with which the feed would update, thus negating the risk of feed readers spamming the servers, somewhat.
  • Extend the default RSS specs to include more extensive per-item author information, to try to ensure that authorship information always remains intact. Extensive metadata would also be useful for cross-site integration.