Adding support for RFC 5005 Feed Paging and Archiving

[jeffbearer]

I just heard about this RFC. I'm going to work on adding support for RFC 5005 to dir2cast. My feed is at 1.2MB containing around 350 shows over 10 years. I hate orphaning the old shows so this sounds like a good solution. I wonder how many clients support this RFC...

[ben-xo]

Did you get anywhere with this? :)

[jeffbearer]

I started adding it. But it got complicated when taking into account the feature that outputs the feed to file, a feature which I find indepensible. I never came up with a good way to handle that.

[jeffbearer]

Following up. I still would like to add this feature. but I think it would require so much re-architecting to the code so that it could write out paged and archived rss files that I didn't expect that you would merge it. That's where I was when I last looked at this.

[ben-xo]

Yeah, that's fair! The idea of the cache file is (obviously) so you only have to regenerate each URL once, and only if the newest file is newer than than the cache file.

You could extend that to only regenerating the relevant page the first time it's accessed, with one cache file per page. Pagination matches up with files, so you'd do the pagination to the correct "sub list" of files, then generate the cage file for that sub list looking only at those files.

Wouldn't scale to tens of thousands but would work okay for thousands.

[ben-xo]

Of course if you're going to that much effort you might as well just put varnish in front of it all and invalidate everything every time you add an MP3

[jeffbearer]

I'm not even talking about the cache file. I use dir2cast to write it's full output to a static rss file. I don't even keep dir2cast.php in the webroot. And for me to modify dir2cast in a way to make me happy is unlikely going to be what you and most others are doing. That's the crux for me.

[ben-xo]

Ah, I gotcha!