Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: [PATCH] New protocol: gemini
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 28 Nov 2020 20:54:34 +0100 (CET)
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.
> I see there is at least tests/data/test1200 that tests gopher. I'll figure
> out how to make something similar for gemini.
Yes, you can most probably implement a gemini test server and have it
incorporated into runtests.pl the exact same way gopher is done. Or perhaps
even like the gophers tests is done if you check that pull-request - since
gemini as a protocol seems very similar to gophers...
> As for documentation -- I grepped source and found very little documentation
> for gopher, other than several mentions that it is supported. What another
> documentation other than that should I add for gemini?
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.
You should make sure that everything that a curl user needs to know about
gemini is provided in the necessary places where protocol differences and
specifics are mentioned. I ask this of everyone who proposes support for new
protocols.
>> The lack of "permanent" redirects and the restricted length on the URLs to
>> be shorter than 1024 would make it hard to work as web replacement protocol.
>
> Redirects are specified by protocol, I didn't figured out how to
> implement them yet.
>
> 30 REDIRECT - TEMPORARY
> 31 REDIRECT - PERMANENT
Right, the gemini document is inconsistent. In the top it says all redirects
are temporary and then further down it says there are also permanent ones...
> Do you consider it pre-condition for merging?
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?
Perhaps also: is it really important to merge support for this protocol if it
doesn't support the protocol basics yet?
>> 'gemini' is not a registered URI scheme:
>> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
>
> Yes, that is true. Is it showstopper?
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?
> 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.
You ask for a -1 timeout there and yes that won't be the right thing to do!
You want a 0 timeout to make it not wait.
Date: Sat, 28 Nov 2020 20:54:34 +0100 (CET)
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.
> I see there is at least tests/data/test1200 that tests gopher. I'll figure
> out how to make something similar for gemini.
Yes, you can most probably implement a gemini test server and have it
incorporated into runtests.pl the exact same way gopher is done. Or perhaps
even like the gophers tests is done if you check that pull-request - since
gemini as a protocol seems very similar to gophers...
> As for documentation -- I grepped source and found very little documentation
> for gopher, other than several mentions that it is supported. What another
> documentation other than that should I add for gemini?
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.
You should make sure that everything that a curl user needs to know about
gemini is provided in the necessary places where protocol differences and
specifics are mentioned. I ask this of everyone who proposes support for new
protocols.
>> The lack of "permanent" redirects and the restricted length on the URLs to
>> be shorter than 1024 would make it hard to work as web replacement protocol.
>
> Redirects are specified by protocol, I didn't figured out how to
> implement them yet.
>
> 30 REDIRECT - TEMPORARY
> 31 REDIRECT - PERMANENT
Right, the gemini document is inconsistent. In the top it says all redirects
are temporary and then further down it says there are also permanent ones...
> Do you consider it pre-condition for merging?
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?
Perhaps also: is it really important to merge support for this protocol if it
doesn't support the protocol basics yet?
>> 'gemini' is not a registered URI scheme:
>> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
>
> Yes, that is true. Is it showstopper?
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?
> 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.
You ask for a -1 timeout there and yes that won't be the right thing to do!
You want a 0 timeout to make it not wait.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2020-11-28