💾 Archived View for rawtext.club › ~sloum › geminilist › 000957.gmi captured on 2020-10-31 at 01:57:07. Gemini links have been rewritten to link to archived content

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

Proposed minor spec changes, for comment.

Luke Emmet luke.emmet at gmail.com

Thu May 21 23:01:14 BST 2020

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

On 21-May-2020 22:50, Martin Keegan wrote:

On Thu, 21 May 2020, Luke Emmet wrote:

If we force one line ending kind on authors, it will be a deterrent

to them forging ahead with writing user content if they have to use

some tool just to be able to get the content onto the server. Look at

XHTML, it was a resounding failure and rejected by authors even

though there were some good (and ill conceived) intentions of the

spec writers.

I believe there's a difference between requiring servers only to use

CRLF in the body, and content authors only to use CRLF. If it were

specified that servers "MUST NOT" send text/gemini bodies that use

line separators other than CRLF, then it remains up to server

implementers to choose whether

1) to require content authors to develop or save their content with

CRLFs, or

2) to translate the content themselves (either on the fly, or by

caching a fettled version with the right line separators).

I see better now what the alternative suggestions are, thanks.

I still think a robust client has to in all likelihood anticipate both CRLF and LF. There will be a range of servers out there and just getting the content of the file sent to you isnt going to be unusual. Probably plain Mac/CR is too ancient to be widely found, but see below.

Another consideration that comes to me now is for any applications of Gemini that might require a binary correct transfer of a text file from A to B. For example if we are gemini as a content transfer layer for a source code repository. There is already a Git over gemini service which seems interesting. In these scenarios as the end user, you would expect that a GMI file served to you from the repo was the same as it is on the server. So I think we should support all "normal" plain text formats as the response body and not in general have the server munging or adjusting them.

Best Wishes

- Luke