On Thu, Aug 25, 2005 at 08:55:48AM +0200, Daniel Stenberg wrote:
> Hi

hi,

> The truth is probably that an author of an application that wants URL
> transfer capabilities by libcurl either relies on
>
> (A) the generic SSL capabilities of libcurl without caring what SSL powers
> that provide it, or the author relies on
>
> (B) some certain features or powers of a specific lib
>
> Let's take one step back again and look at the problem with sane pragmatic
> eyes. (Assuming such exist.)
>
> For the case A, it really doesn't matter what SSL lib libcurl is built
> with, as it should "just work" and if it doesn't it is a bug that can and
> should be fixed. (But if the bug isn't (easily) fixed, this quickly turns
> into a case B)
> Of course we'll have a fixed ABI no matter what SSL lib is used[*].

in case of a gpl application *not* using any ssl functionality the fact
of libcurl being linked to openssl constitutes a license problem.

> For the case B, I'm back on square one and I cannot see how this can be
> provided properly without having a unique libcurl library image for each
> SSL library that it supports (and that are installed in the system).
> libcurl-openssl.so, libcurl-gnutls.so, libcurl-matrixssl.so etc. (With
> libcurl.so being the "default" install which could be a mere symlink to the
> one of the specific libs you think is a proper default.)

i don't know how sane is my idea of using the plugin concept.

you may define a plugin management API and a set of interfaces that
allow multiple plugins to do things (GSS auth with whatever kerberos
implementation, SSL with as many toolkits you like, name resolving
cache,...).

when you have multiple plugins providing similar functionalities,
you could provide basic functionality with any of these plugins and
specific functionalities with specific plugins. you'd provide to the
programmer the tools to probe plugins and check required functionalities.

you make the rules in the APIs provided by a stripped down libcurl
kernel. the user plays his game loading wanted plugins. initially you
would not provide everything as plugin, but with time you could exploit
a powerful design.

regards
domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Received on 2005-08-25