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#v...@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#v...@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
