@brentsimmons totally fair. In concept, a Microsub server acts like the server-side of a reader. It has “channels” which are like folders and in them will be feeds. It fetches feeds, parses them, and normalizes them. @aaronpk is the spec author.
@brentsimmons totally fair. In concept, a Microsub server acts like the server-side of a reader. It has “channels” which are like folders and in them will be feeds. It fetches feeds, parses them, and normalizes them. @aaronpk is the spec author.
@aaronpk Thanks!
Let me see if I understand it. I’ll try putting it into my own words:
Microsub is a spec for a syncing system.
The server crawls feeds, handles feed parsing, and keeps the true copy of the subscriptions list (folders and feeds).
A client app can add/remove folders and feeds and can download the parsed feed data.
(There are additional features, but I think those are the basics. True?)
The two things I think an Evergreen user would still want are: 1) per-article read/unread status syncing, and 2) per-article starred status syncing.
@aaronpk A starred article is a private favorite — generally it means something you want to come back to later for some reason. It’s common to have a special pseudo-feed that shows just starred articles, so a user can find them all easily.
I haven’t worked with current syncing system APIs much yet: my experience is mainly with NewsGator and Google Reader APIs, both now defunct. I vastly preferred NewsGator’s API, because it was designed as a syncing system, where Google Reader’s API was designed for Google, and was never publicly documented or supported, and didn’t work very well for apps like Evergreen (there were lots of ambiguous cases).
@canion This looks really interesting! Thanks for sharing.
My trick to make my 2017 annual review blog post easier to write was to create the draft immediately on publishing my 2016 review. I added little bits to it all year and just polished it off in Dec. I’ve already done the same for 2018.