On Thu, 21 Sep 2006, Camp, TracyX E wrote:

> AFAIK, just that the library be a sort of (de-facto) standard, have
> documentation, tests and be stable (and as a project be committed to
> stability). Libcurl appears to be in pretty good shape on all fronts,
> though perhaps the tests could use some work.

Yeah, they could use some work indeed. But for a Linux-only environment (which
LSB kind of implies) the test suite is pretty stable and good-working. But I
would certainly not turn down any offers that would improve it!

> One potential issue that pops out to me is ssl (a libcurl without SSL
> support is of fairly limit utility).

I don't quite agree that it would be "fairly limited" as it is still a very
useful and powerful library for HTTP and FTP. Still, having it added to LSB
without SSL would still be rather pointless since the majority of all users
would like to replace that with an SSL-capable one...

> LSB works by setting up a development environment that only includes LSB
> interfaces. Part of doing so is wrapping linker commands and whatnot to
> only allow shared libraries that are part of LSB to be linked in.

> OpenSSL is not yet in LSB (nor are any of the other SSL implementations).
> This is something that I'm also working on, but it is in less 'good shape'
> and is just plain a huge library.

Ok, so there's no SSL libs and libcurl is "fairly limited" without SSL.
Doesn't this basically imply that there must be an SSL lib provided first?

> It appears that at least some distributions (Debian being the one we
> checked) places the ssl shared library dependency in libcurl.so, rather than
> having the top level application link it in. AFAIK in LSB this is pretty
> much how these situations have to be handled. (there is no requirement that
> a library in LSB itself be LSB compliant).
>
> Is it possible to build libcurl in this fashion today out of the box?
> If not have you considered it in the past?

I don't understand the difference nor what you ask of us. We provide a lib
that requires a supported SSL lib (one out of three possible for the moment)
for SSL/TLS. If you want that provided in some funny way, what do we need to
do to enable that? Or perhaps, what could we do wrong now that would precent
that?

> I noticed a note about distributions not including your curl-config tool
> (debian is one of these). Other than for picking up link args (which for
> the reason discussed above may be problematic

Well, we are not responsible for what distros do or how they decide to ship
curl and libcurl. We are simply the makers of the tool and lib, we do not
create any packages used in Linux distros.

So, they may be very good or very bad, I actually wouldn't know.

> > The curl_multi_socket() function is not yet deemed stable, but otherwise
> > they should all be fine to use!
>
> Well if it is just the one API, mind if I ask what is preventing stability
> here?

Just more testing and time. I intend to announce it as "stable" in the 7.16.0
release, which is the next public release we'll make.

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