A feed file is a feed represented as a side file (a separate file, as opposed to part of an existing HTML page, like a homepage), typically in a custom feed-specific format (often XML like RSS/Atom, or JSON like ActivityStreams 2.0 or JSON Feed). Feed files are side files that may complement marking up composite streams already visible on HTML pages, e.g. with h-entry and optionally h-feed.
Feed File Formats
A brief list of feed file formats, by recency (most recently updated/improved), and how to contribute to them:
- JSON Feed - contribute via its GitHub issues
- ActivityStreams2 - 2017 W3C Recommendation, contribute via its GitHub issues
- ActivityStreams - IETF draft - abandoned
- Atom - contribute via IETF
- RSS 2.0 (need link to canonical spec) - ???
- RSS 1.0 W3C Recommendation (need link to canonical spec) - frozen at W3C, errata via???
- RSS 0.92 (need link to canonical spec) - possibly obsoleted/superseded by RSS 2.0
Feed files, being separate from actual viewable content on a website, suffer from several problems like:
As a duplicate of information already in the HTML of a web page, feed files are an example of the usual DRY violations.
Higher maintenance (requiring a separate URL, separate code path to generate, separate format understanding)
Out of date
Feed files become out of date with the visible HTML page (often because of broken separate code path), e.g.:
- 2015-02-03: 50 days out of date: http://indiewebcamp.com/irc/2015-02-03#t1422988681803
- 2015-04-26 (reported) :
my RSS failed once for 3 weeks even though I generated it from the same database, because I changed the name of a field! Updated HTML templates but forgot the feed templates, since invisible
Inefficient representation (XML feeds tend to be "wordier" and require more elements, duplication of data, artificial precision in datetimes, etc. all of which add up to higher bandwidth costs etc.)
- Tantek Çelik h-feed at http://tantek.com/ has latest posts with full text contents which is smaller (uses less bandwidth) than the feed file at http://tantek.com/updates.atom (due to reasons noted). This is typical for full content h-feeds vs feed files, and thus typically relegates feed files both unnecessary and inefficient.
Comparing a full-text feed-file vs. summary-text h-feed, the full-text feed-file is more efficient to retrieve. Details:
- Comparision of required bandwidth: Atom feed vs. h-feed size
If feed readers can retrieve a single file that contains all the latest posts with their full text contents, that requires less network traffic than retrieving every permalink page.
Some feed files and h-feeds only have summaries, and thus require all linked entry/item URLs if they want to provide the same user experience (displaying full content and not only headlines).
Previously: The old Monocle would retrieve all linked entry/item URLs until it was closed in 2016.
- no access or discovery of archives
No Since Support
- no way of getting content since a particular datetime
- Criticism: Real world example of an HTML "feed" that demonstrates why RSS was never necessary as a format: http://lite.cnn.io/en from CNN
- Example implied criticism, silent unnoticed failure of invisible non-DRY content: “oops I just realized my photos *feed has been broken for a while” - aaronpk 2019-12-01 indieweb-dev
- Criticism (of RSS in particular, but applies to all sidefiles) https://twitter.com/brianleroux/status/1536479536476454915
- "RSS still works but it's double the work from a publishing perspective. Doesn't address subscription, and more importantly, semantics for publishing from third party either. Atom had some of this...but it's overwrought compared to micro(pub/sub)" @brianleroux June 13, 2022