💾 Archived View for rawtext.club › ~sloum › geminilist › 000461.gmi captured on 2020-09-24 at 02:33:15. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

<-- back to the mailing list

An outsider's view of the `gemini://` protocol

Ciprian Dorin Craciun ciprian.craciun at gmail.com

Sun Mar 1 09:10:31 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

On Sun, Mar 1, 2020 at 10:22 AM Bradley D. Thornton<Bradley at northtech.us> wrote:
> On 2/28/2020 2:04 AM, Ciprian Dorin Craciun wrote:
> 
> On Fri, Feb 28, 2020 at 11:07 AM Sean Conner <sean at conman.org> wrote:
> 
>
>   Why is a numeric status code so bad?  Yes, the rest of the protocol is
> 
>
> English centric (MIME types; left-to-right, UTF-8).  It just seems that
> 
>
> using words (regardless of language) is just complexity for its own sake.
> 
>
> 
> Because numbers are hard to remember, and say nothing to a person that
> 
> doesn't know the spec by heart.  (For example although I do a lot of
> 
> HTTP related work with regard to routing and such, I always don't
> 
> remember which of the 4-5 HTTP redirect codes says "temporary redirect
> 
> but keep the same method" as "opposed to temporary redirect but switch
> 
> to `GET`".)
>
> Well, section 1.3.2 of the Gemini spec-spec says two digit codes, but
> single (first digit) is all that is required. So, a 2, a 20, and a 21
> are all success and there's no ambituity as to anything occuring at the
> first digit level, it's just more gravy with the second digit.


Although I didn't state this before, having two digits, which in factare interpreted as a two level decision tree (the first digit denotinggeneric class of conditions, and the second digit denoting morefine-grained reasons), has at least the following problems:














So, if we really want to keep things simple why not change this into:






How would we automate authentication given we have no `authenticationrequired`?  We display the user the meta, the user interprets themessage and if he sees a message that prompts him to authenticate hewill do so through a menu, and the user-agent will perhaps rememberthis decision.




> I do fail to see why what appears to me to be a whole lot of work to
> implement what you suggest,


Now getting back to my "symbolic" status codes proposal, it's no morework, because currently the code looks like:

Meanwhile my proposal would require one to:````if (hasprefix (status, "success:")) { ...} else if (hasprefix (status, "redirect:")) { ...}````

Granted now one has to implement, or find already implemented the`hasprefix`, but all languages have it, and even in C one canimplement it as `strncmp (status, expected, strlen (expected)) == 0`.

, especially considering that most servers
will invariably choose to implement their own custom handlers for
status/error codes, much like one does in Apache so the server operator
themselves gets to choose what content to deliver as a result of a 404.

No this proliferation of "status codes" won't happen because theprotocol won't allow for it. (Although even today with numeric statuscodes people can just invent their own, unless we clearly defineconditions for all 100 codes, and even then people can disregard theirdefinitions...)

The only marginal advantage I see for numeric codes is in logs as you've stated.

Ciprian.