The 1st comment (from 10 years ago) broke my heart "or you can just "Sort by oldest" in Google Reader."
I miss the internet from back then, just chronological feeds. I think the dead of google reader was a huge the point where websites started to disable RSS feeds and just rely in social media to notify of new content
I almost never encounter interesting content that’s not on a site with RSS feeds. There was one case in the last few years where a personal site did not have a feed, and then there’s foone (sp?) who only writes on Twitter.
On the other hand, there’s not that much that I actually want to follow.
Apparently I've managed not to break this feature! Someone who subscribed to the reverse feed when I'd published this in 2013 (post 740) would have reached the end in June 2019 when I published post 1480.
My posts before ~2009 are pretty bad, though; if they'd given up around post 75 the reverse feed would have gotten them there in June 2018.
Basically, it can scrape a WordPress or Blogger blog into a local DB and then replay the posts one-by-one into an RSS feed.
It's rough around the edges as it was a learning project and I haven't had much time to devote to cleaning it up. But I've been using it for a while and am happy with it.
It's a good idea. I've long wanted a way to subscribe to a shifted version of a podcast, either as a way to slowly consume a new discovery or replay a podcast I enjoyed from the past. It seems much better to make this a feature in the client, though, rather than try to get every producer to produce alternate feeds.
Unfortunately only works for those websites whose RSS feed spans their whole history. Many places nowadays only serve the latest X amount of posts in their feed
Putting only the most recent 10-20 posts in the RSS feed is much better for normal usage, though: fetching every post ever just to learn about whether there's been a single new post is pretty wasteful!
(Ex: on my site that would be 10MB per full feed fetch, 2MB compressed)
> fetching every post ever just to learn about whether there's been a single new post
Usually you'd perform a HTTP HEAD request to see if there's new content by relying on the last modified property, avoiding the need to retransmit the whole thing.
Of course, when the content is updated, you'd need to perform a full refresh. While that's wasteful, there may be a way to use range requests, or skip over the xml stream? It may be harder on the server than just serving the 2-10 MB, though.
In the last 12hr I've had 4,998 RSS requests. Only 6% of these were HEAD requests, so I don't think it's common for feed readers to send a HEAD first and only follow up with a GET if there's a change. Of the GET requests, 55% were trying validation, while the other 45% were just unconditionally requesting the feed. This is not a place where you can trust feed readers to do something sensible if you offer a large feed.
Most APIs that support this kind of "show me a subset of many items" behavior use pagination or specifying date/ID ranges.
I agree it isn't perfect, and like most open APIs, some will do the lazy thing.
Thanks for the numbers. Just a heads up: a single misbehaving implementation can cause a huge spike in traffic, so I suggest you de-duplicate before computing stats.
Maybe this should be a feature for feed readers. Or maybe not exactly this, but some way to go through the archives, keeping track of what you've already read ...
The 1st comment (from 10 years ago) broke my heart "or you can just "Sort by oldest" in Google Reader."
I miss the internet from back then, just chronological feeds. I think the dead of google reader was a huge the point where websites started to disable RSS feeds and just rely in social media to notify of new content
I almost never encounter interesting content that’s not on a site with RSS feeds. There was one case in the last few years where a personal site did not have a feed, and then there’s foone (sp?) who only writes on Twitter.
On the other hand, there’s not that much that I actually want to follow.
For even more obsolescence, that comment was originally posted on Google Plus.
Apparently I've managed not to break this feature! Someone who subscribed to the reverse feed when I'd published this in 2013 (post 740) would have reached the end in June 2019 when I published post 1480.
My posts before ~2009 are pretty bad, though; if they'd given up around post 75 the reverse feed would have gotten them there in June 2018.
Might as well plug my homebrewed solution for this: https://github.com/steadmon/blog-replay
Basically, it can scrape a WordPress or Blogger blog into a local DB and then replay the posts one-by-one into an RSS feed.
It's rough around the edges as it was a learning project and I haven't had much time to devote to cleaning it up. But I've been using it for a while and am happy with it.
It's a good idea. I've long wanted a way to subscribe to a shifted version of a podcast, either as a way to slowly consume a new discovery or replay a podcast I enjoyed from the past. It seems much better to make this a feature in the client, though, rather than try to get every producer to produce alternate feeds.
Unfortunately only works for those websites whose RSS feed spans their whole history. Many places nowadays only serve the latest X amount of posts in their feed
Putting only the most recent 10-20 posts in the RSS feed is much better for normal usage, though: fetching every post ever just to learn about whether there's been a single new post is pretty wasteful!
(Ex: on my site that would be 10MB per full feed fetch, 2MB compressed)
> fetching every post ever just to learn about whether there's been a single new post
Usually you'd perform a HTTP HEAD request to see if there's new content by relying on the last modified property, avoiding the need to retransmit the whole thing.
You can also use ETags: https://web.archive.org/web/20080823141004/http://www.kbcafe...
Of course, when the content is updated, you'd need to perform a full refresh. While that's wasteful, there may be a way to use range requests, or skip over the xml stream? It may be harder on the server than just serving the 2-10 MB, though.
In the last 12hr I've had 4,998 RSS requests. Only 6% of these were HEAD requests, so I don't think it's common for feed readers to send a HEAD first and only follow up with a GET if there's a change. Of the GET requests, 55% were trying validation, while the other 45% were just unconditionally requesting the feed. This is not a place where you can trust feed readers to do something sensible if you offer a large feed.
Most APIs that support this kind of "show me a subset of many items" behavior use pagination or specifying date/ID ranges.
Related: <https://rachelbythebay.com/w/2023/01/18/http/>
No comments for either HN submission.
- <https://news.ycombinator.com/item?id=34435153>
- <https://news.ycombinator.com/item?id=34444109>
I agree it isn't perfect, and like most open APIs, some will do the lazy thing.
Thanks for the numbers. Just a heads up: a single misbehaving implementation can cause a huge spike in traffic, so I suggest you de-duplicate before computing stats.
IIRC, low-tech magazine blocked the Nextcloud News User Agent. They're not the only ones: https://github.com/nextcloud/news/issues/2079
Maybe this should be a feature for feed readers. Or maybe not exactly this, but some way to go through the archives, keeping track of what you've already read ...