💾 Archived View for gemi.dev › gemini-mailing-list › 000607.gmi captured on 2024-03-21 at 17:54:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
# Schapcom gemini://idiomdrottning.org/schapcom 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 to work. Schapcom uses a three-tiered model of Feeds?Curators?Aggregated Feeds. ## 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 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. ## Aggregators 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 > > gemini://idiomdrottning.org/schapcom > > Schapcom is a feed aggregator for Gemini similar to CAPCOM. Nice. > 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. -spc
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 list.
---