Schapcom is a feed aggregator for Gemini similar to CAPCOM.
Schapcom is written in Chicken Scheme using a ton of libraries so it's
not lightweight in that regard. It's just a quick fix to get something
Schapcom uses a three-tiered model of Feeds?Curators?Aggregated Feeds.
Schapcom is compatible with both Gemfeed and Gmisub feed formats.
=> https://tildegit.org/solderpunk/gemfeed Gemfeed
=> gemini://calcuode.com/gmisub-readme.gmi Gmisub
Feeds are Atom feeds (a la Gemfeed) or gmisub feeds.
Curators set up lists of URLs of such feeds that they wanna follow. Each
line needs to end with .xml or .gmi, and this list of URLs should be in
a text file, one url per line, no other lines, no comments no header no
nothing, and end with a .txt file ending. The list of URLs can be on
gemini or on http / https, to minimize the amount of work that curators
need to do. They only need to be able to host a text file, anywhere.
Each Schapcom instance is then pointed to a list of such lists. It
writes a gmi file (similar to CAPCOM's output format) and then
terminates. It shows duplicates-deleted union of entries so it's fine if
a feed is accidentally entered twice, or entered in multiple formats, or
if an entry shows up several times or in several feeds.
So the intent is that a curator's list of follows can be read and used
by several Schapcom instances.
Finding cool feeds to follow is hard work, so leveraging each other's
work around that is the idea.
Run from cron or manually.
schapcom [curator-url1] [curator-url2] [curator-url3] > feeds.gmi
For a repo, git clone https://idiomdrottning.org/schapcom
It was thus said that the Great Sandra Snan once stated:
> # Schapcom
> Schapcom is a feed aggregator for Gemini similar to CAPCOM.
> Curators set up lists of URLs of such feeds that they wanna follow. Each
> line needs to end with .xml or .gmi, and this list of URLs should be in
> a text file, one url per line, no other lines, no comments no header no
> nothing, and end with a .txt file ending. The list of URLs can be on
> gemini or on http / https, to minimize the amount of work that curators
> need to do. They only need to be able to host a text file, anywhere.
Why the hardcoded extensions? It doesn't seem like it should matter given
that you'll get a MIME type of "text/gemini" or "application/atom+xml" that
will tell you what type of feed it is.
I only ask as someone who uses .gemini and .atom as the extensions.
OK, Schapcom now updated to not dispatch on file extensions. (It now
looks at the contents of the file so even the mime types can be
wrong?this is not a deliberate design decision, it just ended up being
the way easier implementation.)
Grumble grumble? This is one of the reasons I was so grumpy about the
gmisub format: it adds work! Now every aggregator app writer needs to be
able to handle two standards. If gmisub had been a tool that read
capsules and output atom, that would've been awesome? Instead, it's a
protocol?an interfacing touch point that we all must now be mindful of.
File extensions does still matter in one circumstance?if a log is
subscribed to in duplicate, Schapcom prioritizes entries from logs that
end with .xml (or, now, .atom). This only matters when the same log ?
the same entries ? is subscribed to in both gmisub and atom.
Put another way, gmisub entries are assumed to be made at noon while
atom entries have a more detailed time description. If the same
duplicate entry shows up, Schapcom uses the file extension to determine
if it's in atom or not. So if you have an atom feed named .broccoli and
a gemsub feed named .asparagus and they contain the same entries, they
might get interpreted as being posted at noon (at that point, it'd
depend on which feed is fetched first). Author of gmisub argues that
this noon thing rarely matters. An argument that I can defer to without
having to agree with?
The reason it has to look at file extensions for this instead of making
requests to get the headers is because it does this by sorting the url