What feed format is best?
benbalter opened this issue · comments
RSS 1.0? 2.0? Atom? Is there any difference in use or reader adoption?
I've found that RSS 2 seems to be the best if you're wanting to use this with iTunes, if that helps?
I've found that RSS 2 seems to be the best if you're wanting to use this with iTunes, if that helps?
I have found this as well, when publishing a podcast.
For all other use cases, I prefer authoring Atom 1.0. It feels like, because it is newer, it had the benefit of hindsight and was able to smooth over some of the rougher edges of RSS.
The problem is that the biggest data provider on the planet uses Atom to feed it's system of news (Google) but that said they are also smart enough to reformat RSS as Atom before feeding it (I wish more companies normalized like that.)
There is a gigundous amount of prior art here, both as gems and in blog post tutorial form. The top 10 Google results:
- batsov recommends Atom.
- snaptortoise/jekyll-rss-feeds seems to use RSS 2 / Atom.
- agelber/jekyll-rss uses RSS 2.
- Drew Inglis recommends RSS 2 / Atom.
- Our good friend Joel Glovier also recommends RSS 2 / Atom.
- Mikel with the cool last name recommends RSS 2 / Atom.
- Mr. Landau here recommends RSS 1, but it's a year old.
- Dave Coyle offers templates for both Atom 1.0 and RSS 2.0.
- Our dear friend and long-time Jekyll user Zanshin recommends Atom.
For reference, <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> = "RSS 2 / Atom".
I'd probably err on the side of Atom, as it's a little more formalized than RSS. We could always offer a configuration option (!!!!!! 🎄 your favourite!).
Looks like you're using RSS 2.0, yeah? https://github.com/jekyll/jekyll-rss-feed/blob/master/lib/feed.xml#L6-L13
👍 on an option, that gives the user the authority.
I was kidding about the option. We have too many options already!
Though I appreciate the South Park reference.
I wasn't kidding about the option, you are forcing a format where no particular format is considered the defacto standard as competing services use competing formats. iTunes likes RSS, Google likes Atom, Facebook likes both, Yahoo likes RSS, our own services accept both.
I won't comment about the too many options part because it's clear that Jekyll doesn't force convention where convention is needed and options out, but in this case there is no convention that is widely accepted, just "preferences" and the keyword there is what should be done.
you are forcing a format
Using this plugin is opt-in, so we aren't forcing anything. The point is to try to limit the number of choices the users have to make to make a site. Jekyll is already pretty complicated, adding an option would make it even more so.
Your argument is facetious to the fact that this is under the Jekyll umbrella which makes it a defacto plugin that will be used by more than not and you are deliberately gimping people because of a problem in Jekyll while claiming that this is not really a piece of Jekyll because it's opt-in.
This argument is outside the scope of this issue now. Convention is better than configuration for new users and old users alike. If you don't want what we give you, write your own damn RSS feed as everyone does now.
I wanted to share this: https://github.com/stve/jekyll-atom
I never released the gem as I was seeking feedback, but it's based off the discussion in jekyll/jekyll-help#7
I'm happy to continue maintaining or hand this off if it's found to be useful.
It sounds like Rss 2 / atom gets us the best of both worlds?
I do write my own "damn" Jekyll RSS/Atom plugin that's maintained for people, just like I have to maintain my own "damn" Jekyll fork to give them what they need fixed in Jekyll2 as well and like many programmers who are tired of maintaining these "damn" forks, I was looking for a way to offload it onto something that would do it right but fair enough, I'll stop here as requested good luck with the plugin.
It sounds like
Rss 2 / atomgets us the best of both worlds?
Where does the "/ Atom" come in? Just because the feeds include an <atom:link>?
Both RSS2 and Atom are viable formats. I'm curious, could the gem provide both? I see an advantage to the site having both feeds available, and then letting the consumer of the feed pick whichever they want.
Doing both does sound like a good approach, if laborious. An old prof of mine (@dret) used to study XML and various formats for syndication. I asked him RSS vs. Atom and he said, "Atom, full stop." I asked him to elaborate and he acted like I was crazy and that there was no debate. So there's that. Maybe he'll chime in now that I've copied him.
When does iTunes use RSS? Are we talking about podcasts here? If so, that's a different thing altogether. For podcasts, they do indeed require RSS.
@mlissner I prefer Atom as well, and in our custom CMS it's the only option currently available (for the past 8 years). We're currently looking to add RSS 2 because we've run into issues where various "widgets" (digital signs as an example) that are capable of consuming remote data for display only support RSS. We've only run into it a handful of times, but it does cause an issue now and then.
could the gem provide both
Pending the discussion over in #4, I think that may be the best approach. As it's been stated multiple times here, there's no clear winner, and I don't know that an either/or option does anyone any good (readers or publishers).
How does /feed.xml (RSS2) and /atom.xml output (in parallel) sound?
Where does the "/ Atom" come in
I may have made that up based on @parkr's comment. I'd never heard of it before. But please feel free to drop some knowledge around formats here if you have any (that's why I opened the issue).
I'm happy to continue mainting or hand this off if it's found to be useful.
@stve I googled around, but didn't see your plugin before heading down this (admittedly short) path. Pending the discussion above, what do you think about combining the two efforts into jekyll-feed (dropping the -atom and -rss)? It looks like you you've got a sold atom template, if you could pull request it here, and otherwise the Ruby looks identical (with the need to abstract both to support multiple files if we head that route).
@benbalter if RSS is only needed for iTunes podcasts (which I assume are really out of scope?) and really niche digital signs, I suspect you could get away with only offering Atom. Not that offering both is a terrible idea...
I've yet to convert over to Jekyll, though I'm in the process, but have been following along for a few months. I'd argue that purely from an open source project standpoint, including a core gem/plugin should only include Atom. I don't claim to be an expert, but I know from experience with another open source blogging engine/CMS we decided early on to only support Atom in core because of its solid RFC and standardized spec. For a general overview of the differences, see this comparison.
As previously mentioned, it's still an optional feature, and those with preference or need for RSS 2.0 options are available.
Where does the "/ Atom" come in
I may have made that up based on @parkr's comment. I'd never heard of it before. But please feel free to drop some knowledge around formats here if you have any (that's why I opened the issue).
For reference,
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">= "RSS 2 / Atom".
This just means that the feed is RSS 2.0, and includes an <atom:link> element (for which there is no equivalent in RSS). It is not really a best-of-both unicorn, it's just RSS 2.0.
Pending the discussion above, what do you think about combining the two efforts into jekyll-feed (dropping the -atom and -rss)? It looks like you you've got a sold atom template, if you could pull request it here, and otherwise the Ruby looks identical (with the need to abstract both to support multiple files if we head that route).
@benbalter I'd be happy to. I'll try to send a pull request later today.
Hoping to summarize where things are at right now best I can:
Reasons to use RSS
- iTunes only supports RSS due to enclosures (but podcasts are not the primary use case for Jekyll or this plugin).
- Wide adoption: most people still seem to think of them as RSS feeds (regardless of the standard used), as evidenced by the posts @parkr linked to, many of which didn't even appear to contemplate using Atom (and underscore the need for a plugin which can pull in upstream updates more easily than a blog post).
Reasons to use Atom
- Less widely adopted by publishers (but it's unclear if any consumers, e.g., feed readers don't support the standard)
- A superior standard in terms of extensibility and future-proofness
Reasons not to use Both
- Adds a non-negligible amount of complexity to the code
- We should take the time to research the current best-of-breed standard, and if there's a clear winner, make the choice for our users, rather than pushing that complexity on to them.
Suggestion
Unless there's evidence that what we'd expect to be a mainstream consumer of Jekyll feeds (e.g, Feedly, IFTTT, Outlook, etc) doesn't support Atom (which my quick research doesn't seem to suggest is the case), I'm going to suggest we adopt Atom, and only Atom, by adopting @stve's Atom template (and refining it from there as needed).
While RSS seems to be more popular among publishers, perhaps for brand recognition reasons, Atom seems to be the superior technology, with near-equal support, IMHO.
I don't care which way you go, I just wanted to point out that the "non-negligible" seems guessed because that's wholly based on implementation no? So you can't assume unless you actually put it to the 1-3 hour test.
Reasons to use RSS
- Plugin can be found when somebody searches for "Jekyll RSS"
As evidenced by the current name of this project, RSS is to feed as Kleenex is to facial tissue.
But, yeah, I'm a big fan of Atom, and I can attest that Feedly and IFTTT both support Atom perfectly well.
They do, and I believe they both format RSS as Atom internally. Feedly more so because it started out as the alternate to Google Reader which preferred Atoms so they are in bed with it for good I'm to assume.
Does Atom support any features that are not in RSS 2.0? What about vice versa? I know I've encountered problems with RSS-format feeds not including stuff like update timestamps, or Atom's equivalent of <id> to avoid duplicate feed entries.
I know I've encountered problems with RSS-format feeds not including stuff like update timestamps
Me too. This is the main reason why I use Atom only.
+1 for Atom... and more importantly +1 for using only one single format!