On Thu, 24 Apr 2008, tetetest tetetest wrote:

> Libcurl defines and uses these handy functions:

Internally, yes.

> Curl_md5it() - computes an MD5 hash of a string;

libcurl only builds with the MD5 code if built enabled, it can also get built
without it.

> Curl_base64_encode(), Curl_base64_decode() - encode and decode data in
> Base64 encoding.
>
> I feel that these functions can come handy in applications that use libcurl,
> so I propose to make them publicly available (with some modifications):

This has in fact been requested before but we've never ended up with an
approach that makes a fine "API" that others would like to use, and at the
same time not put a new extra burden on the lib sources to have stable
_internal_ APIs.

Experience tells that for every new function that we provide to apps, we get
more work so we need to keep the API as small and focused as possible. I'm in
general against providing functions in an official API that concerns
functionality that is not core libcurl related. Things like MD5, base64, URL
fiddling etc.

The curlx_* namespace is a way for others to re-use libcurl *code* to get
functionality already present in the lib, but the curlx_ functions are not in
libcurl's API and we don't make any API promises about them. Using curlx_
functions is only doable if you're willing to adjust and adapt your use of
them with every new release of libcurl. Is that what you're willing to endure?

Historically, the curlx_ code was introduced when I wanted to remove functions
from the public API (to make it more focused) and yet not duplicate the code
for the curl client source code.

> I think these functions should be made public because:
> - they are in the library already, so making them publicly available is
> easy;

It's easy to make something that provides them, it's hard work to maintain it,
to write the docs and to make sure things work the same on all platforms in
all conditions.

> - they are closely related to network tasks: base64 is widely used in many
> protocols; MD5 hashes are widely used in custom authentication schemes,
> email transfers and such.

Sure, but I would argue that most libcurl users have no use for them and
nothing in the interaction with libcurl imposes that you need these. The needs
you mention are completely external and you can then of course mention every
algorithm in the world as possibly used by applications. I don't even see MD5
or base64 as particularly more frequently used by libcurl-using apps (I mean
apart from the transparent use of them that libcurl might do under the hood).

I'm sorry to be this negative about it, but it is my previledge to be the old
and grumpy guy! ;-)

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