For me, it is the only sane way to keep up with my scientific journal reading.
That it's also a fine way to read webcomics and tech blogs is a nice bonus.
11–20 of 358 posts
For me, it is the only sane way to keep up with my scientific journal reading.
That it's also a fine way to read webcomics and tech blogs is a nice bonus.
Earlier quoted context omitted.
https://jsonfeed.org/ has had some preliminary traction. Of course, the reason RSS works so well is that everyone uses the same format. So you wouldn't see so much of a "switch" as a bunch of readers accepting either format, for a very, very long time. That being said, I don't see what's "wrong" with XML in this context.
Most of the complaints I've seen with the 'wrongness' of xml are centered around its human unreadability, which doesn't matter in this context. I'm curious if there's another reason.
By "process" I mean: Read the headline and sometimes the summary, decide whether to read the story, open the story (if I'm reading it), delete the feed item. Repeat 1,000x.
Deduplication is necessary but will only cut items process by maybe 5%, I would guess.
'Grouping' is much more valuable - grouping feed items by topic. For example, after the big event last night, instead of skimming dozens of headlines interspersed among 1,000 others, group together the feed items for that event under a single headers. Then I can quickly pick out the item I want to read and discard the remainder en masse. I'd guess that it would reduce the feed items I need to process by well over 50%.
Other tricks are needed too: 1,000 in 20 minutes is just under 1 feed item per second.
Can part of the renaissance be switching to a JSON format? Please?
Yes, and while we are at it. Can we make HTML JSON based, as well? { "head" : [...], "body" : [ { "name" : "H1", "text" : "Hello JSON" }, ... ] } So much easier on the eye. ; )
I'll repeat my plea for an RSS reader that enables the user (i.e., me) to efficiently process 1,000+ feed items in maybe 20 minutes. Also, it needs to automate aspects of managing feeds (detect when the fail, maybe find a replacement, give me an interface for resolving the problem). By "process" I mean: Read the headline and sometimes the summary, decide whether to read the story, open the story (if I'm reading it),…
I subscribed to way too many feeds in the past and going through them with shortcuts / opening them in the background and then going through the opened pages to read them afterwards works well. It's even quite fast but as soon as you skip a day it just piles up until you can't work off the queue any more.
I then just decided to really look at which feeds I really get most out of and unsubscribed from most of them. Way happier with that strategy and I don't feel like I'm getting overwhelmed by the unread count.
My current combination that I'm happy with for a few years is:
https://miniflux.net + Reeder on iOS and Mac
I'll repeat my plea for an RSS reader that enables the user (i.e., me) to efficiently process 1,000+ feed items in maybe 20 minutes. Also, it needs to automate aspects of managing feeds (detect when the fail, maybe find a replacement, give me an interface for resolving the problem). By "process" I mean: Read the headline and sometimes the summary, decide whether to read the story, open the story (if I'm reading it),…
Earlier quoted context omitted.
https://jsonfeed.org/ has had some preliminary traction. Of course, the reason RSS works so well is that everyone uses the same format. So you wouldn't see so much of a "switch" as a bunch of readers accepting either format, for a very, very long time. That being said, I don't see what's "wrong" with XML in this context.
There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects. For any other language it doesn't matter since you're re-mapping to objects, most likely, but with JavaScript eating the web (even on the server side) I think the question should be "why shouldn't this be JSON" as a default. In the end either way works. I would love to se…
Earlier quoted context omitted.
https://jsonfeed.org/ has had some preliminary traction. Of course, the reason RSS works so well is that everyone uses the same format. So you wouldn't see so much of a "switch" as a bunch of readers accepting either format, for a very, very long time. That being said, I don't see what's "wrong" with XML in this context.
There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects. For any other language it doesn't matter since you're re-mapping to objects, most likely, but with JavaScript eating the web (even on the server side) I think the question should be "why shouldn't this be JSON" as a default. In the end either way works. I would love to se…
Non web-dev guy here, but browsers have excellent XML parses out there that can turn XML into a document object with a fully fledged query language. Why does it need to be a JS object?