Daniel Stenberg wrote: > Our fellow hackers in the Wget project show great interest in joining in an effort to split out the libcurl vtls layer into a separate library/project of its own to become usable by others as well.
> We're starting this right now. Although I understand the pro's of this project, it frightens me a bit for the following reasons: - If the future is to create a separate unbundled library, we won't have any way to use TLS from libcurl unless this library is also installed. - vtls is only a wrapper layer to real TLS API sets: it is fitted to libcurl and has no other value by itself. Other such intermediate layer API (such as https://pki.openca.org/projects/libpki/) have already been attempted: for general use, they only introduced a nth+1 API, one more needed run-time file system object, and therefore are little used. - An unbundling has already occurred with cares with sense (because cares is a true resolver), and with little impact to libcurl, since not having it does not completely disable DNS resolution. From libcurl's point of view, there is no sense in unbundling vtls since the only reason for the presence of this layer is to provide libcurl with a unified interface to the pertaining TLS API. - Dependence on a specific "3rd party" library (as vtls would be considered if unbundled) for a feature as essential as TLS is MUCH penalizing on an OS like OS/400 (and probably others), because no "system standard location" exists for such libraries (i.e.: system standard location is reserved for IBM-provided libraries). As an example, there is neither cares nor libssh2 for OS/400. I fully understand the need for such a unified interface for wget and a certain willingness and usefulness to collaborate with its designers, however I strongly please not to unbundle vtls for the reasons above. Patrick ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
