schannel: stop calling it "winssl" #3504
Conversation
Stick to "Schannel" everywhere. The configure option --with-winssl is kept to allow existing builds to work but --with-schannel is added as an alias.
bagder
force-pushed
the
bagder/Schannel-winssl
branch
from
5204ba9
to
48f8b7d
Compare
|
On 29 Jan 2019, at 10:14, Daniel Stenberg ***@***.***> wrote:
Stick to "Schannel" everywhere. The configure option --with-winssl is
kept to allow existing builds to work but a new --enable-schannel is
added as an alias.
On a related note, should we do the same for Apple Secure Transport and move
away from darwinssl? I’m happy to roll a patch for that should there be
consensus.
|
I think so, yes. I think we're the odd ones here using these names and I think users and people in general will understand our terms better if we use the more appropriate and established names. Darwinssl is slightly more engraved in curl though.
|
|
On 29 Jan 2019, at 10:36, Daniel Stenberg ***@***.***> wrote:
should we do the same for Apple Secure Transport and move away from darwinssl?
I think so, yes. I think we're the odd ones here using these names and I think users and people in general will understand our terms better if we use the more appropriate and established names.
Darwinssl is slightly more engraved in curl though.
CURLSSLBACKEND_DARWINSSL is exposed in the API so we can just rename that, but we can add an alias. It is also the name used for the backend internally so when setting CURL_SSL_BACKEND that's the name to use. Possibly something else.
Cool. I’ll write a patch to see what it would look like.
|
|
I, too, would like to call it Secure Transport. The reason why it was called "DarwinSSL" is because Yang thought "Secure Transport" was too generic a name, but that's what Apple calls it, and no one else uses that name. At the time, I just went with the flow. |
Stick to "Schannel" everywhere. The configure option --with-winssl is
kept to allow existing builds to work but a new --enable-schannel is
added as an alias.