Again on feeds in Gemini format
- 🗣️ From: Omar Polo (op (a) omarpolo.com)
- 📅 Sent: 2020-11-19 10:04
- 📧 Message 5 of 37
Emilis <emilis at emilis.net> writes:
> Hi,
>
> I am developing a generator and a parser for the
> frequently-discussed-but-never-agreed-on feeds in Gemini format.
>
> I would like to share my code, see your similar code and later discuss
> (over IRC?) what format could work best for our use cases.
>
> My code:
>
> Gemlog generator: gemini://tilde.team/~emilis/Makefile
> Aggregator: https://tildegit.org/emilis/gmi-feed-aggregator
>
>
> The motivation (taken from this post:
> gemini://tilde.team/~emilis/2020/11/19-on-feeds-in-gemini-format.gmi
> ):
>
>
> I looked through the discussions on Gemini list, read the posts by
> ~ew0k and Drew DeVault.
>
> I wholeheartedly disagree with the opinion that Atom/RSS (or JSON
> feeds) should be enough for everybody.
>
> The point is - some of us are not thinking about running feed
> generators, parsers and aggregators on developer laptops,
> workstations, modern servers we own, etc..
>
> We are thinking about running these programs on computers where we
> have limited permissions, OpenWRT routers, experimental SBCs, old
> netbooks and rooted phones that cannot be updated to any recent
> distros, etc..
>
> In these situations even Python (widespread as it is) may not be
> available, may be too resource-hungry or may not have the option to be
> updated or extended with libraries.
>
> What we need is the ability to process feeds with a bare minimum of
> tools (e.g. a POSIX shell, BusyBox, etc.). Parsing XML and JSON is not
> feasible in these situations.
With all the due respect, this is a bullshit. Leaving aside that gemini
requires TLS by the spec, even if you don?t have root privileges on a
machine, there is a C compiler on it (how you?re gonna build a shell
without one?), and with that you can build a parser. (I once wrote a
parser with a friend: a couple of hours of fun pair programming and we
had a JSON parser that was able to parse json objects over a socket,
without blocking etc, and was like ~200-300 lines of c code? ? ok, it
wasn?t 100% complete and spec compliant, but you get the idea).
anyway?
> Therefore we want a plain Gemini feed format. Seeing how easy it is to
> generate and parse Gemini files with just plain shell script, makes us
> want it badly. We also have hopes it would have more uses than just
> gemlogging.
I really like the idea! A plain (but structured) text/gemini file would
be better IMHO. It fits the goal of the protocol well: it?s simple,
effective, usable ?as it is? without special client support, easy to
generate (and consume) by humans etc?
> ## What should we do about it
>
> I think we should start by just building the tools for ourselves and
> sharing them (probably on the Gemini list). After we have a few
> implementations, we can discuss on the formal spec between the developers.
I?ve just adapted my static site generator to generate a gemini feed.
The commit for it was just ?3 files changed, 26 insertions, 5
deletions?, as git says. It?s hosted here
=> gemini://gemini.omarpolo.com/rss.gmi
> The main criteria should probably be the amount of effort and
> knowledge needed to implement a parser.
>
> What I found in the discussions is that this may be the lowest common
> denominator at the moment:
>
> ```
> => URL ISO-TIMESTAMP TITLE-MAYBE-WITH-AUTHOR
> ```
>
> We can start from this and agree that our parsers will rely on just
> these lines and ignore the rest for the moment. It could be done by
> this command:
ignoring anything besides the links can be a good idea. For instance,
in my feed I?ve included a title and a quote before the list of feeds:
this can improve the human consumption, but can also let advance clients
to improve the UI: for instance, they could (optionally) extract the
title of the page (the first ?#? title) and use it as a prefix for the
titles, or improve the search, or ?
> ```
> grep -E '^=>\s*gemini://[^ ]+
> [0-9]{4}-[0-9]{2}-[0-9]{2}(T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|\+[0-9]{1,2}:[0-
9]{2}))?\s+.*