4 ms·
Anything that has updates and doesn't need to be an instant notification. It's rather the other way around. Nowadays everything is a website. News is a websit
by bhaak 3y ago
Anything that has updates and doesn't need to be an instant notification.
It's rather the other way around. Nowadays everything is a website.
News is a website. GitHub commits, pull requests, issues, etc. are websites, too. Social media posts or replies are websites.
Some of those use cases used to be handled by mail, some of them are now done with browser notifications. I would consider a persistent standard log a need that is not handled by anything else than RSS though.
- rollcat 3y ago> Anything that has updates and doesn't need to be an instant notification. I wonder if there's an easy/obvious way to enhance RSS with instant (or near-instant) notification capability. Perhaps HTTP long polling/Websocket? For small setups, it wouldn't scale/cache as easily as "check this URL every hour, and remember to include ETag/If-Modified-Since", so perhaps for public feeds it could be done via a specialized aggregator / caching proxy network? Maybe model the API after Pushover? <https://pushover.net/api/client#websocket https://pushover.net/api/client#websocket> Use cases is any kind of feed that can update in very short intervals (minutes), or benefits from quick round-trip times, but the exact update frequency can be extremely irregular. For example status alerts, social media posts, blog/forum comments, security updates.
- deleted 3y ago[deleted]
- moritz 3y ago“websub” is what you are looking for: https://www.w3.org/TR/websub/ https://www.w3.org/TR/websub/
- rollcat 3y agoIt seems this is a server-to-server protocol? Subscriber is required to accept HTTP requests, which makes it mostly useless for most contexts where RSS is used.
- Minor49er 3y agoIt's a little funny to me that the response to "these notifications don't need to be realtime" is "let's make RSS realtime"