Re: [PATCH] New protocol: gemini

From: Dmitry Bogatov NOT AFFILATED via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 28 Nov 2020 20:59:28 -0500

I believe my previous reply was dropped by mailing list.

On Sat, Nov 28, 2020 at 08:54:34PM +0100, Daniel Stenberg via curl-library wrote:
> On Sat, 28 Nov 2020, daniel#haxx.se#v1_at_kaction.cc wrote:
>
> Why do you put that crap in your From: line that makes it look like to
> people as if I am the author of your email? Your name and address surely has
> nothing to do with daniel, haxx or se. Please stop that.

This is how I fight spam. And given that

        curl-library#cool.haxx.se#v1_at_kaction.cc

is the email subscribed to list, this is the only email I can send thing
from. I will take care to reply to list, not to you personally in
future.

> Don't compare with gopher. Nobody is proposing to add support for gopher in
> 2020. You are proposing we add support for gemini right now. Gopher is in
> many cases a bad example.

Okay, I'll check HTTP documentation instead.

> There's no exact list of requirements for accepting a new protocol into
> curl, but let me say it like this: it doesn't help to leave out stuff. The
> fact that you *can* leave out protocol details and still consider it "fine
> enough" also maybe hints that this protocol isn't used enough for this to
> matter, and if these details don't matter, maybe it is too early for curl to
> consider it?
>
> What do other gemini clients do? Aren't redirects used by gemini servers?
> Are there (more than three) public gemini servers deployed?

Other clients do redirects:

>>= diohsc gemini://tilde.pink/~kaction/dist
        . >>> gemini://tilde.pink/~kaction/dist
        . +-----[X509]------+
        . |+ +.o oO |
        . |.B = + O o |
        . |+ * O X + . |
        . |.= & * o o |
        . |+oX = ^ |
        . |=* E |
        . |+. |
        . | . |
        . | |
        . +----[SHA256]-----+
        . Expires 2021-02-06
        . >>> gemini://tilde.pink/~kaction/dist/
        Directory listing

        [1] /~kaction ..
        [2] flake-dhall/ flake-dhall/ Nov 22 2020

> Perhaps also: is it really important to merge support for this
> protocol if it doesn't support the protocol basics yet?

From my personal point of view -- yes. Because I do not recall using -L
option for http(s) ever. But obliviously, I undersand your position that
things should be merged only when everything works.

> Everything is taken together and considered as a whole. When the amount of
> bad signs pile up, they become a pile bad signs and those are not the piles
> we want.
>
> If you're serious about this being a real protocol with a defined URI (RFC
> 3986 defines URIs, not URLs, and yet your spec calls them URLs all the way)
> syntax, then why haven't you registered the scheme?

Never though about it. I am just a user, after all.

But as you mentioned it, I started discussion on gemini list. I hope
gemini author will agree to participate in registration process.
>
> > I tried (and it worked) to replace this check with
> > SOCKET_READABLE(sockfd, -1) before read, but it looks like it would
> > block concurrent transfers, so it is likely wrong too.

Does

        if(SOCKET_READABLE(sockfd, 0) <= 0)
          return CURLE_OK;

(which works) make sense?
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-11-29