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
---
Previous in thread (44 of 63): 🗣️ solderpunk (solderpunk (a) SDF.ORG)