Proposed minor spec changes, for comment. (???)

peteyboy@sdf.org <peteyboy (a) sdf.org>

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/
>> > >
>>

Link to individual message.

---

Previous Thread: Adding gemini protocol to curl

Next Thread: Zain, a Tcl/Tk gemini client