💾 Archived View for rawtext.club › ~sloum › geminilist › 005684.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Omar Polo op at omarpolo.com
Fri Feb 26 13:01:21 GMT 2021
- - - - - - - - - - - - - - - - - - -
Stephane Bortzmeyer <stephane at sources.org> writes:
On Thu, Feb 25, 2021 at 10:16:52AM +0100,
Omar Polo <op at omarpolo.com> wrote
a message of 161 lines which said:
As things stands, I know I can
cat file1.gmi file2.gmi ...
result.gmi
and obtain a valid text/gemini file.
One of the things missing in the current specification is a formal
grammar of gemtext, so there is currently no way to know if lines must
end with a end-of-line or is the end-of-file sufficient.
=
gemini://gemini.bortzmeyer.org/gemini/missing-eol.gmi Example
Amfora and Lagrange seem to accept the last line (the one without an
end-of-line). But your example with cat would break it, concatening
the last line of the first file with the first line of the second file.
It's not completely true. This example was specifically for UNIX-likesystems where files are expected to end with a newline. It's POSIXfault, as it defines a line as a sequence of character ending with a \n:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
(this isn't an excuse for clients to not handle them correctly though!)
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?
Because humans (specially non-anglosaxon humans) have trouble with
"From", "Subject" and "Message-ID"?
I can agree, but I find preferable something like
# Hypothetical archive page for a Gemini mailing list in Italian
Da: Omar Polo <op at omarpolo.com> A: <someone at example.com> CC: ... Oggetto: [spec] proposta per i metadatai
``` actual raw body of the e-mail... ```
instead of
-: x-mail-from="Omar Polo <op at omarpolo.com>" -: x-mail-to=<someone at example.com> -: x-mail-subject="..." ``` ... ```
or even
``` actual body of the email ```
^^^ from: ... to: ... ...
"Free-form metadata", as in simple text paragraphs made up like that,are probably already widespread, intuitive for writers and readers, andprobably also "simple enough" for tools to grok, at least partially. Italso solves localisation problems, because it's the author that is freeto pick the way he/she prefers to conveys the meaning for his/heraudience. Different authors may choose different keys for the same"idea" (i.e. "Updated", "last-updated", "edited" ...), that's true, thissolution is not without its drawbacks.
(ah, all of this without adding dangerous ways to extend the text format)
If we want to build a better GUS I don't think that adding metadata
to text/gemini will solve anything, it will actually make things
worst. The point is, you can't trust 3rd-parties metadata. [...]
people will abuse the metadata to "go up" in the search results, and
the outcome of that is crystal-clear on the Web,
I'm not convinced by this "look at the SEO mess" argument. Gemini is
not the Web, there is no money at stake, marketing people and salesmen
frown upon Gemini ("what, no pictures? No tracking?") so I really
doubt that many people would resort to dirty tricks just to be higher
in GUS' results.
I acknowledge that this is not a problem right now, and hopefully willnever be, but we should be aware of the troubles. Adding a syntax formetadata will (possibly) open the doors for tracking, styling, etc.