💾 Archived View for rawtext.club › ~sloum › geminilist › 000862.gmi captured on 2020-11-07 at 01:49:03. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Proposed minor spec changes, for comment.

jan6 at tilde.ninja jan6 at tilde.ninja

Tue May 19 10:23:21 BST 2020

- - - - - - - - - - - - - - - - - - -

May 19, 2020 10:46 AM, "solderpunk" <solderpunk at sdf.org> wrote:

So now the question is which do we prefer, forcing servers to

canonicalise (canonise?) everything, with client behaviour then being

strictly limited, or letting servers just send whatever the author uses

and forcing clients to accept any of CRLF, CR or LF?

In general I have preferred pushing burden to server authors over client

authors for Gemini...but I expect the client burden is pretty small here

as most languages will have some kind of functionality for breaking

strings into lines which already handles this...

Cheers,

Solderpunk

well, if it's ONLY CRLF, then it enables making basic clients in *ANY* language, including pure assembly, if someone were brave enough (well, the core part, you'd probably write the TLS part in C or something, still)

maybe change the spec slightly, so, after the header, there's CRLF, immediately after which is an empty line with the line ending that applies for the rest of the document, and require at least one non-empty line after that?that wouldn't matter for more advanced languages, which can just ignore that and use builtin functions, but for more basic ones, it makes it easy to read, "is it LF, else is it CR followed by LF, else assume CR"... while it would be possible to do that with normal content lines too, it'd be harder, as you can't just "eat" a byte or two from the start...