💾 Archived View for rawtext.club › ~sloum › geminilist › 002602.gmi captured on 2020-09-24 at 03:00:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Jacob Moody moody at posixcafe.org
Tue Sep 8 19:45:27 BST 2020
- - - - - - - - - - - - - - - - - - -
I talked about this a bit on #gemini but though I could collect some of my points here for posterity.
On 9/8/20 12:31 PM, easeout at tilde.team wrote:
RSS and Atom are well-supported formats. They are XML, but you can
probably import a parser / generator rather than having to write one
yourself.
Part of the beauty of gemini to me is that there is really no bar to entry in terms of requirements of what the system has to have before you start. There is tls but I think having this encryption requirement is more then reasonable(even if I have reservations on the design of tls). The requirements on using something that uses XML would limit the ecosystems that gemini could exist on. I loved seeing the adaption in otherwise limited software stacks like plan9, in which the complexity of things like xml parsing has prevented a readily usable library to exist on the platform.
This proof of concept demonstrates that any Gemini page can already be
treated like a feed. This means that, if you don't mind not
participating in the broader internet feed reader ecosystem, and you
don't mind the occasional page redesign creating noise in subscription
results, you don't have to make a feed file at all. Syndication is
zero-cost.
This is fantastic. With just one page could be used for both a human readable index as well as something like a feed. Having a single page for both I think is really in the spirit of how I interpreted this protocol. The fact that you could whip up something this small to process feeds like is a testament to the simplicity of this type of system already.
Gemtext authors could feel like they are not burdened with creating a
feed file if browsers, feed readers, and aggregators allowed subscribing
to Gemtext pages directly. When as an author you understand that a feed
file is unnecessary, the pressure to create a feed file is lifted. But
for that to happen, you have to see direct Gemtext subscription working
in the wild. One way that could work is for a browser to have a way to
treat a bookmark like a feed subscription. I also think if CAPCOM would
accept Gemtext pages as a feed URL option, that would go a long way.
I don't think something like this would stop people from using something like atom or so on as their own feed system, which I find more then fine. If servers would like to, they could even offer an automated way of creating those types of feeds based on something like the Gemtext implementation. I would consider this type of feature to evolve over time for which ever feed system is chosen regardless. For me personally I think this satisfies the 'complexity when you want it and none if you dont' attitude that I find attractive. What I am trying to avoid here is the expectation that servers need to provide an xml based feed and the expectation that clients should parse it.
Thanks,Moody