Daniel Stenberg wrote:

> My intention here is to properly see what we can do and what's
possible. I don't want to harm libcurl with this so everythin done with
vtls needs to be done so that very little extra will be necessary for us
to use it. If that objective fails, a separate vtls simply won't be used
by libcurl.

Many thanks for your reply, Daniel. This seems reasonable.

> Also to address your concerns about a 3rd party library, I could very
well imagine vtls to be like glib or to offer glib-like properties,
where you actually incorporate/copy the files into your project and
build with them so they never appear as a 3rd party library. I'm not
saying it will end up like that, but it would be one way to handle such
a concern.

I've never used the glib this way and even didn't know this was
possible. This seems however a good idea to get rid of an external
library. In addition, keeping a source bundle in libcurl's file tree
will offer the advantage to be able to pull-in the desired backend
directly from libcurl's compilation rather than being tight to the
"external vtls" choice. Maybe a git submodule ...?

And remember: if we have a total backend abstraction (at the compile
level), we cannot use crypto facilities from the (unknown) TLS backend
and we'll have to use our own, unconditionally... unless you decide to
support crypto API from vtls, in which case this must be emulated (maybe
platform-dependent) as it is now in libcurl if not included in the real
TLS backend.

Cheers,
Patrick

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-02-09