💾 Archived View for rawtext.club › ~sloum › geminilist › 000959.gmi captured on 2020-09-24 at 02:13:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Matt Brubeck mbrubeck at limpet.net
Fri May 22 01:45:20 BST 2020
- - - - - - - - - - - - - - - - - - -
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 workwith 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 forsupporting "\r" line endings, nor for other uncommon newlines likeU+2028 LINE SEPARATOR:https://github.com/rust-lang/rfcs/pull/1212
I think text/gemini should allow both "\n" and "\r\n". Requiring asingle style would either place a burden on content authors (onservers that don't auto-convert line endings), or make servers morecomplex and less efficient. (They would need to inspect everytext/gemini file and possibly transform it, rather than stream itdirectly from disk to the network.) Meanwhile, I think clientsoftware can handle either option fairly simply.
For the protocol header, I don't have a strong opinion. Any choice wemake is fairly easy to implement in both server and client. However, Ihave a slight preference for specifying just "\n" as the headerterminator. One byte is (marginally) more efficient than two, and insome languages it's slightly simpler to split on a single-bytedelimiter.