Proposed minor spec changes, for comment.

[✈個展]

I think what Martin is saying is some of what I was trying to convey at
with my "gemini-fmt idea" proposal on another thread… that Gemini content
authors run their texts through a spec conforming tool before a text ever
reaches the servers and clients of Geminispace.

Whatever combination of CR, LF or CR LF is in the pre-conformed text it
will be correct when it gets on the server and correct when it gets to the
client if run through such a tool.

The people who are writing the server and client software are doing a huge
service to the Gemini community, so please don't saddle them with the
admittedly tedious work of writing code to check in the server and then
check again in the client if it is an improper combination of CR, LF or CR
LF and then even more code to re-conform it. That kind of thing really
seems to go against the 100 lines of code, code it in a weekend Gemini
spirit in my opinion.

Thanks for your consideration.

J

On Thu, May 21, 2020, 16:18 Martin Keegan <martin at no.ucant.org> wrote:

> On Thu, 21 May 2020, solderpunk wrote:
>
> > We basically need to choose between forcing server authors to normalise
> > all endings to CRLF or forcing client authors to recgonise LF (even
> > though it'll probably never be seen in the wild).
>
> Could we have a bit of a breather to allow the implications to sink in,
> and, critically, to allow the development of conformance testing tools?
>
> If there were a tool which could be run on a document, that confirmed that
> it was conformant, and a similar tool for server behaviour, and people
> had had some time to try to integrate these with the existing
> software, it'd be easier to assess the tradeoffs involved in the spec
> decision.
>
> Mk
>
> --
> Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/a6c3faea/attachment.htm>