💾 Archived View for rawtext.club › ~sloum › geminilist › 000960.gmi captured on 2020-09-24 at 02:13:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Nicole Mazzuca nicole at strega-nil.co
Fri May 22 03:02:47 BST 2020
- - - - - - - - - - - - - - - - - - -
I am a strong proponent of "follow the existing practice if there isn't good reason to change". I personally think CRLF should be recommended, but not required for content, as text/* is wont to do over HTTP; I think expecting clients to deal with any of {CR, LF, CRLF} is totally fine. However, the header should _absolutely_ end in CRLF, as every existing protocol works this way.
Nicole
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Thursday, May 21, 2020 5:45 PM, Matt Brubeck <mbrubeck at limpet.net> wrote:
On Thu, May 21, 2020 at 1:47 PM solderpunk solderpunk at sdf.org wrote:
Some quick experimentation with Python revealed that str.splitlines()
is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
For what it's worth, the Rust standard library is designed to work
with both LF ("\n") and CRLF ("\r\n") line endings, but not CR alone
("\r"):
https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
In the discussion that led to this, there was no real support for
supporting "\r" line endings, nor for other uncommon newlines like
U+2028 LINE SEPARATOR:
https://github.com/rust-lang/rfcs/pull/1212
I think text/gemini should allow both "\n" and "\r\n". Requiring a
single style would either place a burden on content authors (on
servers that don't auto-convert line endings), or make servers more
complex and less efficient. (They would need to inspect every
text/gemini file and possibly transform it, rather than stream it
directly from disk to the network.) Meanwhile, I think client
software can handle either option fairly simply.
For the protocol header, I don't have a strong opinion. Any choice we
make is fairly easy to implement in both server and client. However, I
have a slight preference for specifying just "\n" as the header
terminator. One byte is (marginally) more efficient than two, and in
some languages it's slightly simpler to split on a single-byte
delimiter.