[ANN] Schapcom

Sandra Snan sandra.snan at idiomdrottning.org
Thu Jan 7 09:00:49 GMT 2021


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.


More information about the Gemini mailing list