Difference between revisions of "Reading page RSS"

Revision as of 22:59, 4 February 2009

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.
  • The former is not a "pro"; someone asking for something doesn't influence its goodness. -xb
  • The latter is true, but is that good? We could also add a telnet interface, or raw DB access, and those are "an extra way for people to interact with site content" but I'm sure we'd both agree they're bad. -xb
• Could potentially be use full in cross-site integration.
  • Yes, potentially, but I'd still be scared of the load this would cause to have federation rely on RSS feeds. -xb
• 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.
  • I don't feel a burning need to implement something just to do it "right" or demonstrate to others that they're doing it "wrong". -xb
• In theory, serving RSS should be less bandwidth intensive than serving HTML.
  • This presupposes that users load it less. Given how automated an RSS feed will tend to be, I'd argue they will end up loading it more. Could be wrong, though, I have no evidence to support my claim. -xb

Overall, the list of "pros" seems pretty thin to me... I don't really understand why people want this feature, what they intend to use it for, why it's better than the reading page, and how it will overall benefit the community of DW. -xb

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.
  • Easy enough to work around, we can solve this. -xb
• If the security setting of an entry is made more restrictive, a version grabbed from the feed may persist longer than the author wished.
  • This "problem" exists with the reading page in general and isn't unique to this feature, so I wouldn't list it here. -xb
• In practice, people having feed readers automatically polling the site every 30 seconds could lead to increased site load.
  • We can rate limit pulling the feed relatively easily, so if usage does become a problem, we can solve it. Or restrict to paid users only, too. -xb

I would also add:

• Breaks down some of the community aspect of the site by potentially discouraging participation by isolating users from the site. -xb
• Feature becomes nearly useless if we allow content owners to say "do not allow my content to be aggregated". (Would you really use an RSS Reading Page feature if you knew that 50% of the posts on it would require you to click back to the site to read?) -xb

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.