>> On Fri, 17 Nov 2017, Daniel Stenberg wrote:
>>
>>> Nowadays though. Is anything or anyone using this feature (disabling
>>> CURL_GLOBAL_SSL) for a good purpose and if so, can you please elaborate on
>>> why and how? (I don't think "I won't use any TLS protocols" is a good
>>> reason.)

Just to belatedly chime in, I think the usage case where TLS is not wanted
would be a LOCAL area network where an application is talking to a bunch of
dumb devices. Perhaps some sort of lab with a bunch of sensors with embedded
controllers being polled by a smarter host of some sort. It might even be
reporting across a wide area network and want SSL for that, so it would have a
secure/insecure mix. I don't see this as being too much of a problem for a
libcurl-using app as long as it is not being repeatedly. If the program is
being respawned, or is invoking the curl utility, then there might be some
significant overhead due to the repeated re-initializations of the crypto.

This is the only 'burn' usage scenario I can think of. It is not my current
scenario, but as one who formerly did embedded things, I still tend to think
small. The unpreventable overhead of initializing an unneeded library seems
non-trivial. Maybe with current processors the overhead is negligible. I'm
not sure what the low end might look like these days.

Otherwise, this is a completely reasonable thing to do.

Cheers!
Rich

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-12-05