💾 Archived View for rawtext.club › ~sloum › geminilist › 004766.gmi captured on 2024-03-21 at 16:48:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 nowlooks at the contents of the file so even the mime types can bewrong—this is not a deliberate design decision, it just ended up beingthe way easier implementation.)
Grumble grumble… This is one of the reasons I was so grumpy about thegmisub format: it adds work! Now every aggregator app writer needs to beable to handle two standards. If gmisub had been a tool that readcapsules and output atom, that would've been awesome♥ Instead, it's aprotocol—an interfacing touch point that we all must now be mindful of.
File extensions does still matter in one circumstance—if a log issubscribed to in duplicate, Schapcom prioritizes entries from logs thatend 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 whileatom entries have a more detailed time description. If the sameduplicate entry shows up, Schapcom uses the file extension to determineif it's in atom or not. So if you have an atom feed named .broccoli anda gemsub feed named .asparagus and they contain the same entries, theymight get interpreted as being posted at noon (at that point, it'ddepend on which feed is fetched first). Author of gmisub argues thatthis noon thing rarely matters. An argument that I can defer to withouthaving to agree with♥
The reason it has to look at file extensions for this instead of makingrequests to get the headers is because it does this by sorting the urllist.