💾 Archived View for rawtext.club › ~sloum › geminilist › 005614.gmi captured on 2023-11-14 at 09:58:47. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Oliver Simmons oliversimmo at gmail.com
Thu Feb 25 10:23:45 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote:
I think this is a bogus point. I never contributed to OSM, but from
what you're saying I suppose they use something like XML/SGML/... Those
things are *meant* for extensions (the 'X' in XML stands for that),
whilst everything around Gemini is focused on non-extensibility and
simplicity, even at cost of missing features.
I'm not talking about XML/etc, that's an entirely separate topic.I'm talking about the key=value system.
But instead of thinking about what we may add, let's think about what we
have:
- we have TLS because it's fundamental to guarantee confidentiality
between servers and clients
- we have status codes, because a page that says "an error occurred"
or "certificate required" cannot be interpreted correctly otherwise
- we have a media-type in the response, so users know what kind of
document they're getting
These are all about the protocol, not Gemtext.
- we have links, so we can connect different pages, even across
different capsules
- we have titles, paragraphs, quotes and lists to express and organize
our writings
- we have pre-formatted blocks to allow certain types of
explanations/presentations that otherwise would have been impossible
(how do we teach how to write text/gemini in text/gemini?)
From here you can notice how humanly-centric Gemini is. We don't have
features for bots (more than what it's absolutely needed at least) and
even more importantly we only have basic and necessary stuff. There's
no fluff in Gemini.
If you think about it, we only have features that we can't objectively
live without (no links? no paragraphs? no media-types? ...) while we're
lacking various things that would be "nice to have".
Specification section 5.5 - Advanced line types:
The following advanced line types MAY be recognised by advanced clients.
Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function.
I agree though, unnecessary features shouldn't be added.
We don't have headers, because with them comes extensibility and
complexities, and we're getting just fine without them. We don't have
inline formatting because it's difficult to handle client-side and we're
doing really fine without, etc.
Extensibility *is* an issue with metadata, but this applies to Gemtextas a whole due to its nature of being text-based, who's to stopsomeone from creating a new line type that their client understands?Standardising metadata now would make people less likely to add it intheir own weird formats in the future, and laying down solid rules ofwhat is and isn't allowed as metadata in Gemini documents helps inavoiding (it doesn't prevent entirely) people from adding styling orother weird things in the future.
On the opposite side, adding metadata would make it easier for peopleto add new things like styling, if they ignore what it's intended for.Neither side of the argument really wins here in my eyes.
- (your?) proposal of the ^^^ toggle line, while eastetically nice
(I'll give you that!) has the additional drawbacks of breaking the
concatenation. As things stands, I know I can
cat file1.gmi file2.gmi ...
result.gmi
and obtain a valid text/gemini file. With your proposal, I have to
write a parser that analyzes every file. There are a lot of people
who uses simple scripts/makefiles to generate their capsules with
standard UNIX tools, this would (possibly) break them. And even
worst, the cat(1) example I gave before will break only *sometimes*,
depending on the content of the files. (let's not talk about how to
merge metadata from multiple files...)
I hadn't thought about that, a very valid point.But I think allowing metadata to be mixed in with text, as the otherformat allows, is a bigger drawback than enforcing putting it at theend of files and breaking concatenation.Having both the opening and closing toggle lines would fix this, butit would allow moving and splitting up metadata thought files again.
Also, the examples you gave in support of your proposals seems bogus
too. Serving a mailing list archive over Gemini? Cool, but why convert
the mails to text/gemini? Wrapping them in ``` (with headers visible)
or serving them "raw" is not enough?
Yup, they're pretty pointless, there aren't many specialised 'good' use cases.
Why I think metadata will make things like GUS worst? While full-text
search is not without its drawbacks, as Bortzmeyer reminded us, people
will abuse the metadata to "go up" in the search results, and the
outcome of that is crystal-clear on the Web, other than making the life
of who makes a SE more difficult, as now they also have to try to
understand if the metadata is actually relevant or not.
Reverse is also true.Look at some recipes on the modern web, or a news article.Recipes will have a 'backstory', for some reason Margret's cookieswill have a few paragraphs explaining how they improved her life andhow this (bog standard) recipe has descended through her family.News articles are changed to be repetitive and often thehighest-ranking ones in search results don't actually go into muchdetail.
I'm not saying that metadata doesn't also have this issue, I'm sayingit applies to everything, not just metadata.
Now, to get off-topic:
[0]: mine? I would love to have a syntax for definition lists and
3-levels of unordered lists.
If you mean ordered lists with your first point they would be ~fairlyhard for clients to parse compared to other line types, they don'tstart with a static first three characters. (See spec section 5.3 -"Line-orientation")1. Hi2. Foo3. BarWorks fine anyways with plain text, it just doesn't have as niceline-wrapping as quotes and unordered lists.
Multiple levels of unordered lists actually wouldn't be very hard:* Hi** And welcome*** to my list* Boop!** Booyah!
[1]: .gms is GeminiScript of course. A minimal, non-estensibile and
simple scripting language for your preferred client, hoping it
doesn't lack support for it /s
burn. it. with. fire.
- Oliver Simmons (GoodClover)