4 ms·

I run a podcast hosting service. Every day we push between 20 and 30GB of RSS feeds out into the world. In the same time frame, we push about 150KB of JSONFeed

I run a podcast hosting service. Every day we push between 20 and 30GB of RSS feeds out into the world. In the same time frame, we push about 150KB of JSONFeed data. RSS is a clunky tool that's difficult to extend. Extensions end up being duplicated by vendors that consume the data in slightly different ways. The ability to embed rich content in a feed is limited and nonstandard. To your average user, the functionality comes off as "this seems broken" instead of "what an amazing ubiquitous standard." If I had a quarter for every support request about why "Podcast App X isn't showing my links" I could cut my prices. RSS is not a good format. On top of that, it has obvious omissions. There is no standard way to do pagination. Podcast feeds need to include _every episode_ with full metadata for the back catalog to be available. For podcasts that publish every day for years, this adds up to megabytes. If you think parse/execution times are bad with JS, imagine the work your phone is doing when it chews on a few meg of XML every half hour for all those shows you're subscribed to that don't publish episodes anymore. RSS is bad and broken. It still works, but it's like IRC (or how IRC used to be): it solves the core needs of many people in the most mediocre way possible and everything else is a hack or just outright doesn't work. I really wish there was enough demand for a better standard.

xkapastel 8y ago
Does that amount of RSS data include Atom? If so, what is the ratio, and if not, how much Atom do you serve?
- bastawhiz 8y ago
  I don't serve Atom, simply because it's not as well supported.
monksy 8y ago
JSON won't resolve that issue for podcasts that you've subscribed to that don't publish anymore. That's either a cache issue from a static resource or a service issue that doesn't support the cache response. Also, the issue with the size of the rss feed: It all comes down to how the settings are set. Is it set to full syndication of the article, or is it summaries. Either way, JSON won't solve that issue. JSON isn't going to fix your issue with non-standard attachments to the articles. It's going to make it worse.
- chipotle_coyote 8y ago
  You keep referring to "JSON," but the parent post referenced "JSONFeed." The question you should be looking at isn't whether JSON is somehow better than XML in an objectively measurable way; it's whether JSONFeed is somehow better than RSS in an objectively measurable way. And in fact, JSONFeed does resolve that issue for podcasts that don't publish anymore, because it has an "expired" key that indicates that. One of the other problems that the parent post mentioned has to do with pagination, and JSONFeed handles that issue, too -- which again, RSS doesn't. JSONFeed also supports attachments in a better fashion, allowing for alternate representations of the same thing (e.g., different audio formats). Extensions are baked into JSONFeed rather than being a slightly dubious hack. The spec also supports things that have become common in the last decade-plus that RSS and Atom simply don't handle, from simple things like including favicons and banners to real-time notification endpoints. https://jsonfeed.org/version/1 https://jsonfeed.org/version/1 JSONFeed has come up before on HN and the same kind of "why do you think it's better because it's JSON" questions came up. I guess we can argue about whether the bike shed looks better when it's painted with braces or with angle brackets, sure. But it's not the JSON part that makes JSONFeed better; it's the "we've thought about what we've learned in the 16 years since RSS was last materially updated" part that makes it better.
  - nickm12 8y ago
    "JSONFeed has come up before on HN and the same kind of 'why do you think it's better because it's JSON' questions came up." If JSONFeed has practical improvements over RSS/Atom, they've done a terrible job of promoting that. The initial (and to this day only) blog post and the intro to the spec imply that the only problem JSONFeed is trying to solve is to avoid parsing XML, which is just not a problem to many developers.
- bastawhiz 8y ago
  The size is an issue because XML is much more costly to parse and query than JSON, in my experience. But even if that was solved, there are a ton of other more pressing issues to solve. WRT zombie podcasts, you can't expect users to say "I'm paying for this hosting but I'm done publishing episodes". They always think they'll get around to publishing more. And in my experience, they end up letting the show go only when their credit card expires.
sebst 8y ago
> Podcast feeds need to include _every episode_ with full metadata In my experience, most publishers just don't include the full series of historic episodes, but only the last 10/20/100/... This makes it even worse because now the client is responsible for syncing (an episode might have been deleted forever or just fallen out of the top-N list by recency). In your experience, do you often see full historic RSSs?
- bastawhiz 8y ago
  We always serve full historic RSS. If we didn't, there would be no way for most listeners to consume the old audio. When you use a third party service like mine, you either need to use the website that I provide for that back catalog (a bad experience for the listener) or jump through hoops to maintain a separate copy of each episode on your own website so it's still available if the feed is truncated. In neither world is that a decent experience for the content producer or the listener.
Youden 8y ago
> There is no standard way to do pagination. RFC5005 is the standard and covers both Atom and RSS: https://tools.ietf.org/html/rfc5005 https://tools.ietf.org/html/rfc5005 No idea how many apps support it but Podcast Addict does at the very least: https://podcastaddict.uservoice.com/forums/211997-general/suggestions/4251734-support-for-paged-feeds https://podcastaddict.uservoice.com/forums/211997-general/su...
_emacsomancer_ 8y ago
And like IRC, RSS is still better than any of the other things on offer.

xkapastel 8y ago

Does that amount of RSS data include Atom? If so, what is the ratio, and if not, how much Atom do you serve?

bastawhiz 8y ago
I don't serve Atom, simply because it's not as well supported.

monksy 8y ago

JSON won't resolve that issue for podcasts that you've subscribed to that don't publish anymore. That's either a cache issue from a static resource or a service issue that doesn't support the cache response. Also, the issue with the size of the rss feed: It all comes down to how the settings are set. Is it set to full syndication of the article, or is it summaries. Either way, JSON won't solve that issue. JSON isn't going to fix your issue with non-standard attachments to the articles. It's going to make it worse.

chipotle_coyote 8y ago
You keep referring to "JSON," but the parent post referenced "JSONFeed." The question you should be looking at isn't whether JSON is somehow better than XML in an objectively measurable way; it's whether JSONFeed is somehow better than RSS in an objectively measurable way. And in fact, JSONFeed does resolve that issue for podcasts that don't publish anymore, because it has an "expired" key that indicates that. One of the other problems that the parent post mentioned has to do with pagination, and JSONFeed handles that issue, too -- which again, RSS doesn't. JSONFeed also supports attachments in a better fashion, allowing for alternate representations of the same thing (e.g., different audio formats). Extensions are baked into JSONFeed rather than being a slightly dubious hack. The spec also supports things that have become common in the last decade-plus that RSS and Atom simply don't handle, from simple things like including favicons and banners to real-time notification endpoints. https://jsonfeed.org/version/1 https://jsonfeed.org/version/1 JSONFeed has come up before on HN and the same kind of "why do you think it's better because it's JSON" questions came up. I guess we can argue about whether the bike shed looks better when it's painted with braces or with angle brackets, sure. But it's not the JSON part that makes JSONFeed better; it's the "we've thought about what we've learned in the 16 years since RSS was last materially updated" part that makes it better.
- nickm12 8y ago
  "JSONFeed has come up before on HN and the same kind of 'why do you think it's better because it's JSON' questions came up." If JSONFeed has practical improvements over RSS/Atom, they've done a terrible job of promoting that. The initial (and to this day only) blog post and the intro to the spec imply that the only problem JSONFeed is trying to solve is to avoid parsing XML, which is just not a problem to many developers.
bastawhiz 8y ago
The size is an issue because XML is much more costly to parse and query than JSON, in my experience. But even if that was solved, there are a ton of other more pressing issues to solve. WRT zombie podcasts, you can't expect users to say "I'm paying for this hosting but I'm done publishing episodes". They always think they'll get around to publishing more. And in my experience, they end up letting the show go only when their credit card expires.

sebst 8y ago

> Podcast feeds need to include _every episode_ with full metadata In my experience, most publishers just don't include the full series of historic episodes, but only the last 10/20/100/... This makes it even worse because now the client is responsible for syncing (an episode might have been deleted forever or just fallen out of the top-N list by recency). In your experience, do you often see full historic RSSs?

bastawhiz 8y ago
We always serve full historic RSS. If we didn't, there would be no way for most listeners to consume the old audio. When you use a third party service like mine, you either need to use the website that I provide for that back catalog (a bad experience for the listener) or jump through hoops to maintain a separate copy of each episode on your own website so it's still available if the feed is truncated. In neither world is that a decent experience for the content producer or the listener.

Youden 8y ago

> There is no standard way to do pagination. RFC5005 is the standard and covers both Atom and RSS: https://tools.ietf.org/html/rfc5005 https://tools.ietf.org/html/rfc5005 No idea how many apps support it but Podcast Addict does at the very least: https://podcastaddict.uservoice.com/forums/211997-general/suggestions/4251734-support-for-paged-feeds https://podcastaddict.uservoice.com/forums/211997-general/su...

_emacsomancer_ 8y ago

And like IRC, RSS is still better than any of the other things on offer.