-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, September 21, 2006 1:17 PM
To: libcurl development
Subject: Re: libcurl in LSB?

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

> I'm doing some preliminary work to scope the effort necessary to
include
> libcurl into LSB.

Neat!

> I'm interested in any comments, concerns and issues about putting
libcurl in
> LSB.

Feel free to ask specific questions if you have any, as I have no clues
about
what LSB requires from a lib like libcurl, but I know a fair bit about
libcurl.

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.

There is of course more to LSB inclusion than that, but the rest is
mostly on the LSB side of things. And naturally the details are where
the work is.

One potential issue that pops out to me is ssl (a libcurl without SSL
support is of fairly limit utility). 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.

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

> Are there parts of the public API that are not stable? Looking
through the
> change log seems to indicate that portions of the multi interface
might be
> undergoing further change in the future. Inclusion in LSB does not
always
> mean all APIs supported by a library go in if the developers do not
consider
> them stable.

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?

Thanks!

t.

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