💾 Archived View for rawtext.club › ~sloum › geminilist › 000971.gmi captured on 2020-09-24 at 02:12:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
peteyboy at sdf.org peteyboy at sdf.org
Fri May 22 17:36:16 BST 2020
- - - - - - - - - - - - - - - - - - -
My only two Gemini files were composed in nano in sdf shell. I like being able to just write a file and not worry about stuff.
Also the point someone made about git is, I think, something to consider wrt jacking around with file contents vs just working with them.
On May 22, 2020 12:02:04 AM PDT,
Message: 1
Date: Thu, 21 May 2020 17:05:03 -0500
From: ??? <jetkoten at gmail.com>
To: "A protocol that is slightly more complex than gopher, but
significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
Subject: Re: Proposed minor spec changes, for comment.
Message-ID:
<CANW6ZfHn+ZoZREyFAzBj3NDs_sqDBPk5mvJiOe4248QuHhBtpw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
But is it a zero sum game like that really (either make it hard on
server
authors or make it hard on content authors)?
The would-be Gemini content author at this point in the game will be
someone who either has created an SSH key and SSHed into a pubnix, used
Git
to send their content to a Dome style server or used sftp to upload
their
hand written Gemini text.
Is it truly making their life harder to enter:
gemini fmt mytext.gemini<Enter>
and thereby save the server and client authors from having to do all of
that checking logic? They're still are many other ways they can enjoy
the
moving target development against an evolving spec aren't there?
:)
I hope my idea doesn't seem hostile somehow, because it's not intended
to
be in any way. I just figure save everybody effort and complexity,
everybody wins? feed two birds with one seed.
Thanks
On Thu, May 21, 2020, 16:52 solderpunk <solderpunk at sdf.org> wrote:
On Thu, May 21, 2020 at 04:28:19PM -0500, ??? wrote:
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.
I'd rather make life a little harder for developers - who are
technical people who know what a CR and LF are and are, anyway,
signing
up for a bit of fiddly detail by undertaking to implement an internet
protocol from scratch - than make life harder for content authors,
who
may have no idea what this nonsense is all about and are arguably
doing
an even bigger service for the community by providing something to
use
our present abundance of servers and clients to read.
Sorry if this seems blunt!
Cheers,
Solderpunk
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/0569461b/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 21 May 2020 17:45:20 -0700
From: Matt Brubeck <mbrubeck at limpet.net>
To: "A protocol that is slightly more complex than gopher, but
significantly simpler than HTTP" <gemini at lists.orbitalfox.eu>
Subject: Re: Proposed minor spec changes, for comment.
Message-ID:
<CAD1=23kgc=xipusFfpfquYYO14h9AW+=JQe8cBy-N4Cxq9GSmg at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.