💾 Archived View for rawtext.club › ~sloum › geminilist › 002601.gmi captured on 2020-09-24 at 03:00:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Meff meff at meff.me
Tue Sep 8 19:17:42 BST 2020
- - - - - - - - - - - - - - - - - - -
easeout at tilde.team writes:
However, some of us are concerned with the complexity of creating a feed
alongside creating Gemini content. If one of our goals is to make Gemini
content easy to publish, making it easy to syndicate is an attractive
goal too. And it is jarring to go from writing Gemtext, which is
remarkably simple and straightforward, to writing Atom XML, or to
finding a static site generator tool that will do it for you. This feels
like a cost. It might remind us of the bloat on the web we are trying to
do without. Or it might be a barrier to entry for users who would be
confident publishing Gemtext, but not confident publishing Atom, or for
that matter, a web page.
At this point in time, how many folks can write Gemtext but aren'tconfident writing HTML? Yes, for those that hand-author feeds, it'scertainly a bit of a bother writing XML by hand (I've screwed it upmyself a few times), but I'm not sure theGemini community is at the point where we have users that are confidentwith Gemtext but not with HTML.
# Subscribing to any Gemtext page
To get a feel for that, I did a proof of concept that you can try out:
=
https://github.com/kconner/gemini-subscription-cli Proof of Concept
This repository contains a Makefile and a shell script. The script takes
a list of Gemini URLs to fetch, which are expected to be Gemtext pages.
It filters them down to just the link lines. It compares the set of link
lines with a previously-fetched set of link lines, and it identifies and
emits those that are new. It saves the new total set as the next run's
previous set for comparison.
If there's just a shell script parsing text and making socat commands, what'sstopping an author from using `jq` or `xidel` on the output to parseJSON and XML respectively? I realize in code it's not that simple, butmost languages in general use have JSON and XML parsers easily availableand generally well documented.
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.
One of my favorite parts of Gemini is the attitude that it works with therest of the net, as opposed to trying to cloister itself like the Webdoes. One of my pet peeves with the web is how it tries to reinventeverything. Long-lived connections, push protocols, things that TCP hashad _forever_.
In hindsight, why does RSS exist? What is "Really Simple" about it?
Well, it's simpler than HTML. If HTML was easy enough to parse, you
could just subscribe to web pages and not need feed files. But Gemtext
is already easy to parse. We don't our experience on the web to mislead
us into thinking a page, like your blog index page, is not already a
subscribable list of links.
Small aside: Semantically annotated tags have been a dream for the W3Cfor quite some time now, and annotating feed links and other tags is thepurpose behind Semantic Web initiatives. The web has definitely tried toallow in-band feeds.
Gemtext authors could feel like they are not burdened with creating a
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 still feel like this is NIH, but I'm not a CAPCOM or Spacewalk authorso a decision like this isn't my place. As long as we continue to haveAtom/RSS support, that's all I'd like. I guess if there is a broadermove to Gemtext feeds, there should be pretty simple methods availableto convert those into Atom-compatible feeds.
- meff