On Wed, 29 Mar 2006, Gonzalo Diethelm wrote:

> 1. How difficult was to add SSL support for libcurl?

It of course depends on what you mean with "difficult" and what you consider
"SSL support" to be. It is probably very dependent on how much you know about
SSL in general and your SSL lib of choice in particular.

> I have always had the (maybe fancy) notion that libcurl evolved to support
> all of its non-SSL functionality, and then someone said "ok, now let's add
> support for SSL"; hopefully the impact of this work on the existing code
> base was very little?

That notion is not entirely correct. Or rather, it is correct but that day in
the past when someone decided to add SSL support was back in 1998 and curl was
nowhere near what it is today. And even then, the SSL support was added pretty
much the same way as other things are added in libcurl: it was done to work
for the cases the authors had and as far as I understood it at the time.

Since then the SSL code has changed considerably and not a lot of the original
code is left untouched.

You can still today see us change things in the SSL code, doing bug fixes,
changing behaviour and adding new stuff.

Of course this doesn't actually imply that it is "difficult" per se, but
mostly reflects how we work in this project. Also, the state of SSL support
added in 1998 was very basic and done with the SSLeay library that wasn't at
all as complete and stable as the current OpenSSL or GnuTLS libs are.

> 2. I will definitely "use the source, Luke", but I would love to get any
> hints and caveats on what to look for, what to avoid, etc., when I start
> adding SSL support to SWILL.

I'd say that the hardest part was and I think still is, the lack of good
OpenSSL documentation. The GnuTLS lib is somewhat better documented and have a
cleaner and more consistent naming and behaviour etc.

The good part of today is that you'll be able to dig up lots of existing
source code that already did this work and you can easily get inspired by
other's hard work to let you do shortcuts to avoid possible wormcans.

> 3. Sometimes asking oneself the reverse question helps: how difficult would
> it be to RIP SSL support OUT of libcurl? How entangled is SSL into libcurl?

I don't think that answers the question very good. It simply answers the
question how good we have managed to abstract or layer the libcurl source
code. And since you can easily build libcurl with or without libcurl the
answer would be: it would be next to instant to rip it out.

> How modular are the interfaces?

libcurl features its own internal layer to keep the actual underlying SSL
library hidden from the rest of the lib, in order to make it easier to build
with OpenSSL *or* GnuTLS (and possibly other future libs we could add support
for).

> Does any of this change when one uses OpenSSL vs GnuTLS?

Some things change, but they can be fixed too given some time and effort.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html