On Thu, Aug 25, 2005 at 02:30:18PM +0200, Daniel Stenberg wrote:
> 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.

Yes, true - it's not really necessary to do it at run-time.

> 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.

I think that is a nice idea! Similar to my "libcurl-ssldummy" proposal,
it'll use curl-config to do the "linking magic", but additionally it
doesn't require an empty dummy library.

> 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.

Oh, it'll be OK to have just one libcurl package which contains both the
OpenSSL lib2 and the GnuTLS one. AFAICT there's no legal problem with this.

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

If you as upstream mandate different library names for the two variants,
this would be OK WRT cross-platform compatibility. Hm, but then you'd need
*three* different names; one more for the libcurl without any SSL support.
In the future, you'd need yet more names for further backends.

This is a somewhat weak argument, but personally I feel that it's "not
nice" to have the code duplicated in 3 or more libraries.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯