This feed is 25 megabytes:
Over 5 years of items in it. I think the need for <podcast:archive> is clear.
@dave Something similar to Atom Link tag with 'next' attribute would be great. That allows the feed to provide a ling to another feed containing older episodes. That way you can go back to the 1st episode if you want to
@podcastaddict Did you see the tag proposal?
Feels like a good start I think.
@dave @phoneboy @podcastaddict I first saw it as a recomendation in https://podlove.org/paged-feeds/ and once I used jekyll-octopod, a static site generator for podcasts (recently went out of maintenance), that supported paged feeds: https://github.com/jekyll-octopod/jekyll-octopod/blob/7f9b751cc2e0997bf57162116d44ffb683445a16/assets/_layouts/feed.xml#L19
@dave @phoneboy @podcastaddict I did a quick manual search on a list of feeds I have, I could find at least one hosting solution that supports it (seems popular, the analytics of my app showed a lot of feeds from it), https://www.omnycontent.com/d/playlist/a858b0a5-e5e6-4a14-9717-a70b010facc1/8c82ca25-0115-4298-a9d7-a8cb016519ad/68596700-adcd-4c41-9c95-aa1d01170641/podcast.rss
@dave yes I like that. As well as what podcast addict said with the atom link tag
@dave it's a trap. Opening that totally jammed my mobile chrome 😅.
@dave WOW! I thought _maybe_ they had large <content:encoded> blocks, but no!
Checking the episode count it reminds me of the opening of Portal 2: "nine nine nine nine …"
@dave This is why we have a feature in powerpress called feed maximizer that minimizes the feed information beyond a set number of episodes.
@Todd_Blubrry What does it do with the old ones? Archive them somehow, or just move them out of the feed?
@dave This is one of my biggest beefs with feeds - no paging functionality. Don't love the IETF solution either of <link rel="prev-archive" href="[PREV_FEED_URL]"/>. Feel like there should be a simple way to request the feed with an offset or page number value.
I also think the <podcast:archive> proposal is lacking because it requires offering a way to request a single full archive feed file which lazy apps could just request every time.
@dave Maybe just having *.rss?offset=12 or *.rss?pg=2 still allows the feed's policy of how many episodes per feed file to be maintained.
@nathan Hmm. Bringing in url parameters seems out of scope for the namespace, but I do catch your meaning. Having just one big archive is tough. The good thing about RFC5005 is that it handles both dynamic and static feed generation pretty well. For hosts that produce and store static feeds, a dynamic offset in a url param would require a big refactor.
@dave Agreed, it's kind of outside the namespace but I think solving everything through namespace might not always be best. Thankful for your work on this!
@nathan Yeah, that's good to remember for sure. Gotta use the right tool for the job.
@nathan ..."right" being its usual subjective self. 😂
Since inception Omny Studio has supported paginated RSS feeds using the RFC5005 <atom:link> spec for obvious performance/bandwidth benefits. Unfortunately, support for paginated feeds in apps has been spotty (but props to Podcast Addict).
@dave @jamescridland @podcastaddict Notably the Apple Podcasts app still does not, which means it will only display the number of items on the “first page”. (Furthermore Apple Podcasts directory will only show 300 but that’s not an issue in the app)
By default, we paginate by 100 episodes/items (subject to change), however we offer customers/publishers the ability to override their "pagination size".
@dave @jamescridland @podcastaddict Some of our customers, like the one in question, have a preference to show their entire catalogue in the RSS feed to their audience, which means to cater to the lowest common denominator and disable paging.
Whilst the <podcast:archive> proposal is interesting, we believe the already established RFC5005 spec addresses the same problem and allows for more responsive user experiences when navigating, especially when the archive actually becomes quite large.
@longzheng @jamescridland @podcastaddict If we can get a feel for some of these things it’ll help decide if it’s worth “duplicating” that functionality into the podcast namespace. I’ve seen a couple of times where there is an existing standard but hardly anyone uses it. In that case, bringing it into the “podcast” namespace could actually help it get adoption more broadly. I’m building a stats tool right now to track which hosts are using which tags.
Intended for all stake holders of podcasting who are interested in improving the eco system