Hurrah! I have those listed in likely order of resource/climate impact, so if I could nudge you towards considering (1) sooner then even bettererer! B^>
In addition to performance it also has to do with politeness: it’s not polite to ask for the same resources again and again from a server when you could cache it, especially when it has explicit headers about it in its response. Think of small self-hosted blogs with hundreds of readers that constantly poll it.
Even with a small self-hosted blog, assuming you have more than a 56k hookup to the internet, a raspberry pi can service up 100s of requests per second.
At the time of writing this, the HN rss feed is 12kb. That'd mean you'd need 10Mbps upload to handle 100s of requests to the rss feed per second.
(Again, not saying you shouldn't optimize this, just questioning how big a problem it is).
When I was being low-grade DDoSed the other day my off-grid RPi3B server was taken out by ~60 bogus requests per second. It is otherwise entirely happy with normal HTTP loads, plus being primary DNS server, SMTP, NTP, ...
One podcaster halved its bandwidth bill overnight getting just one of these fixed, see "A saving bandwidth special!":
I am trying to better assess this number as part of an arXiv paper I am putting together. Maybe even this weekend!
RSS/podcast feed polling is a load for which Apple/Amazon/Spotify/Podbean are currently wasting 99%+ of the network and CPU bandwidth for, and thus money and carbon emissions. Many of the creators have limited budgets, and reaching Net Zero is not going to happen by ignoring really easy cases such as this, albeit small in the overall scheme of things.
Looks nice. But I'ts strange that there are so many "simple" feedreaders. Where are the tools for powerusers? How many feeds and formats are people using usually to be satisfied with simple?
Not the OP but my biggest missing features would be:
- the ability to send the output of one smart query into the input of another
- not needing to escape every quotation mark in a query, and maybe the ability to combine operands eg ( title =~ {linux,macos} as opposed to title =~ \"linux\" or title =~ \"macOS\")
- a dashboard mode that can show a snippet of the top headlines and maybe autoscroll
- ability to mark an article as read after a certain delay
I've started working on my own "power user" RSS reader that lets you weight the keywords you're interested in (so an article that hits important keywords but is older could be displayed above an article that's newer) but it's still closer to a proof-of-concept than a complete app.
I think this is one of the reasons I started using rss2email back in the day - I could do the filtering, searching, and manipulation using my preferred email client.
Originally that would have been mutt, later my own client, and later still I switched to gsuite.
I did add support for excluding entries/posts based on title, body, regular expression, and similar, but at the end of the day I just fetch all feed entries and save them as emails. The later processing can be done by any client and that's pretty flexible. There's very little custom processing required in the RSS-processing itself.
A good GUI with Real scripting. A portable version. Maybe better documentation. A client/server-architecture, or some other kind of headless mode with remote access.
