💾 Archived View for gemi.dev › gemini-mailing-list › 000132.gmi captured on 2024-03-21 at 16:55:42. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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.
---