cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: more on GnuTLS vs OpenSSL vs ...

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Thu, 25 Aug 2005 14:30:18 +0200 (CEST)

On Thu, 25 Aug 2005, Richard Atterer wrote:

> On Thu, Aug 25, 2005 at 10:31:09AM +0200, Domenico Andreoli wrote:
>> i don't know how sane is my idea of using the plugin concept.
>
> This was also one of the first things I thought of, but curl is portable to
> a huge set of platforms, and the approach would only be portable to a
> handful of them. So I figured that Daniel wouldn't like it. :-7
>
> I agree that it would be a nice solution - maybe the configure script could
> just check if dlopen() is there, and fall back to the current way of
> building if it isn't.

Why is it necessary to have it as a plugin? To me, a plugin means that it can
be decided and loaded run-time, while I see little benefit in doing the
decision in run-time.

With a "plugin" system we'd have to create one new plugin for each underlying
SSL library we'd support.

Instead, we could just make a new lib (let's call it lib2) that libcurl
requires to do SSL, that has a standard API/ABI. lib2 can be linked with one
out of a wide selection of SSL libs. So, when you link your app that uses
libcurl to do SSL, you link with libcurl, lib2 and the underlying SSL lib.

In Debian, you'd have lib2-openssl and lib2-gnutls installed, but only one
single libcurl. Each app will then depend on libcurl and one of the lib2
versions.

But I don't really see why the plugin concept or the lib2 concept is much
better than the two libcurl versions concept...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2005-08-25