Daniel Stenberg wrote:
Hi friends,
After my talk at Fosdem I got some questions and there were voices raised
regarding our unified internal API for SSL/TLS libraries. There seems to be at
least some interest from other parties to be able to re-use it in other
projects.
I know that maintaining and offering a library with a stable API/ABI,
documentation and more is a lot of work, but I'm still curious to hear if
there are others around here who would be interested in seeing such a
development? (and of course possibly participate in making it happen)
A benefit for libcurl could be that we'd get a few more hands involved in
polishing the code for various TLS libraries. The benefit for others would be
that it would be easier for them to support a multitude of TLS libraries.
After all, the "pick your TLS library" game is widely played out there.
I wouldn't be surprised if anyone else have tried something similar already so
if anyone knows about something like this, it could be worth investigating to
see what lessons there are to learn!
At one point I had OpenLDAP's libldap able to support OpenSSL, GnuTLS, and
MozNSS simultaneously (runtime switching per socket, not a compile-time
config), but I backed down from that because it didn't seem like anyone would
ever actually use that functionality. Overall, it seems as long as you
(general "you") support OpenSSL and any other alternative, you've done enough
and can move on with the rest of your project.
IMO, freedom of choice is only valid when all the choices are of equal
technical merit, reducing the choice to just personal taste. There may be a
multitude of TLS libraries, but they are definitely not equivalent in
technical merit.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
