💾 Archived View for gemi.dev › gemini-mailing-list › 000132.gmi captured on 2023-11-04 at 12:27:37. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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/ >> > > >>
---