Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I work more with podcast feeds vs article feeds, but the most important lesson I learned when it comes to RSS is that what readers actually do has is not necessarily what you would think, or sometimes even not what the spec says. It's the wild west, even with major readers, and you have to do the work and test in different players if you're producing your own RSS.

We have a huge internal document of how RSS elements map to UI in every player and all the gotchas, and we still discover new things years after initial development.



The problem is that there are huge swaths of use cases that are not covered by the current rss standard. For example, want to use standard RSS for your video feed? Ooops! RSS does not support thumbnails, duration and a bunch of other features.

So everyone goes ahead and makes their dialect of RSS and pushes that. Apple did this with iTunes and so did YouTube.

What clearly needs to happen is that RSS needs to have a refresh. The common uses cases need to be integrated into the standard.


“Dialect” implies that this is ad hoc, but the RSS 2.0 standard specifies a way to extend the format and that is through namespaces, which is exactly what Apple does with the iTunes namespace. This is a good way to extend the format IMO: no breaking changes and the opportunity to grow.


In practice the incompatibility comes less from new invented fields (that happens rarely and when it does it has a namespace attached to it most of the time), and more how certain fields are interpreted, which fields are used, etc. Something as simple as showing a short summary of an item varies significantly by player.


With podcasts at least there's a solid effort behind this with the podcast namespace (https://github.com/Podcastindex-org/podcast-namespace) - unfortunately there's very little uptake on the player side.


>We have a huge internal document of how RSS elements map to UI in every player

From another comment:

>The problem is that there are huge swaths of use cases that are not covered by the current rss standard.

Have you considered turning that document into a RFC to establish a standard?


The problem is there's not really even a defacto standard. At least as far as podcasts are concerned, some players will use certain fields in completely different ways, ignore other fields, include their own vendor specific fields (with some other players adopting those vendor specific fields).


It would be nice if you’d made those findings publicly available.


Yeah, that's a really good idea and made me put on my list to make that public (there's a couple of issues with it being public in the state it is in now)


This sounds like a lot of fun (to me!), where do you work, if you don't mind me asking, and are you hiring by any chance?


Always! Reach out at ryan at supercast dot com





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: