[SPEC] Backwards-compatible metadata in Gemini
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
> - 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 Gemtext
as a whole due to its nature of being text-based, who's to stop
someone from creating a new line type that their client understands?
Standardising metadata now would make people less likely to add it in
their own weird formats in the future, and laying down solid rules of
what is and isn't allowed as metadata in Gemini documents helps in
avoiding (it doesn't prevent entirely) people from adding styling or
other weird things in the future.
On the opposite side, adding metadata would make it easier for people
to 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 other
format allows, is a bigger drawback than enforcing putting it at the
end of files and breaking concatenation.
Having both the opening and closing toggle lines would fix this, but
it 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 cookies
will have a few paragraphs explaining how they improved her life and
how this (bog standard) recipe has descended through her family.
News articles are changed to be repetitive and often the
highest-ranking ones in search results don't actually go into much
I'm not saying that metadata doesn't also have this issue, I'm saying
it applies to everything, not just metadata.
Now, to get off-topic:
> : 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 ~fairly
hard for clients to parse compared to other line types, they don't
start with a static first three characters. (See spec section 5.3 -
Works fine anyways with plain text, it just doesn't have as nice
line-wrapping as quotes and unordered lists.
Multiple levels of unordered lists actually wouldn't be very hard:
** And welcome
*** to my list
> : .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)
More information about the Gemini