It’d still totally leverage X-Ray for parsing feeds, and use Yarns-like polling—WebSub may be a future option. The client bit would be more of an RSS reader and less of a social media app.
Laravel’s scheduler would make all of this so easy. But: if I use the built-in `hourly`, `everyTwoHours`, `twiceDaily`, etc. schedules, lots of feeds would still get downloaded at the exact same time (_on_ the hour). So, I can either use `hourlyAt($minutes)` to spread things out a bit, with `$minutes` a random offset (and somehow skip rarely updated feeds that I deem “not yet due”). Or simply use `everyMinute` and something like a `next_check` column to only fetch and process overdue feeds.
Surely there’s quite a bit that can be borrowed from Aperture. Not sure if I want extensive filters and what not. (Maybe you should, you know, just unfollow feeds you don’t enjoy reading. Anyhoo, we’ll see.) Not sure if the JS modals are a keeper, either. Not a big fan of ’em, although they are interesting (and kind of work well here).
“Really easy.” I’ve given the channels as categories some more thought, and editing sources outside of channel context isn’t too easy, either, _if_ you want to offer “channel-specific source settings,” like if the aggregator should try and fetch original web pages rather than save just the feed summaries. (In Miniflux, which knows only categories, and limits them to one per feed, this is a source-specific setting. Or rather, user-specific source setting.)
Having `source_user` rather than `channel_source` would clear up some of this confusion. And `entry_user`, perhaps, so that we can still filter entries in a user-specific (rather than channel-specific) way. Or we drop all that and just parse feeds. And filter dynamically, if we must. That’s what RSS readers do, I think—not sure. They don’t offer different channels. One category per source, and limited options otherwise. Ima look at FreshRSS’s code.
Looks like FreshRSS may be single-user, which is a heck of a lot easier. As soon as you go multi-year, you’ll want to centrally process feeds—poll them once, not once per “owner”—yet allow different users to give ’em different names. Aperture does that, uses `channel` as an intermediate model, works great. Thing is, as soon as you’ve got per-user source settings, you’ve gotta store these per channel. And since sources can belong to multiple channels, there’s going to be duplicate settings.
That’s it. That’s the thing. There’s either going to be duplicate (per-channel) data, or it’s all going to be done per source (per user), with channels merely acting as labels—as categories. (I’m guessing actual channels are somehow inspired by TweetDeck’s columns or so? In that they _might_ show different entries of the same sources, because of filters and all. Having spent a couple years using traditional RSS readers, I really had to get used to “channels.”)
Could it be an option to limit sources to a single channel, at least through the UI? Sure. Make it a select menu. Make it possible to add a source from anywhere in the app, and override the current channel, if any, using the select box value. Make it editable after the fact, too. That could work. (I’m now using checkboxes to easily move or copy sources around, but I don’t think it’s 100% secure in multi-user environments. And it clutters up the UI.)
Knew I’d seen this somewhere! https://aperture.p3k.io/docs
@jan SSGs?
@Canageek Static site generators. Or CMSes, come to think of it. I mean, they may switch CMSes, too, and forget about auto-generated routes and stuff.
@jan So… basically a systemd timer? :)
@bekopharm A bit like WordPress’s “cron system.” Gets run every couple minutes and runs actions that should’ve been run. systemd is out of the question, thing has to be pure PHP (plus a single Linux cron job).
Just remembered Laravel has built-in model serialization. We should use it. Now wondering if `hasManyThrough` could used to tie entries to channels—it’d be less flexible, though, than the current implementation.