Hey friends!

* Background

As I've been hinting about previously, I have been leaning back and forth on
how to deal with code that we add to the library that the app (curl) also
could use. Once upon the time I added new functions to the libcurl API for
this (curl_mprintf, curl_strequal, etc) but as the years have gone I've grown
up to become more grumpy about these matters! ;-)

Now I think differently. Now I want libcurl to feature less functions that
aren't transfer-related. Let libcurl do what it does best, and stop doing the
rest (at least stop providing functions for that).

While we have to live with our (my) past sins for a while more (we can't just
remove a bunch of existing functions, as that would punish lots of app
authors) I've decided to stop adding more of this kind of functions. libcurl
should not provide functions just because 'curl' needs them too.

* Why is this relevant right now?

When we added large file support to libcurl, we added an internal strtoll()
replacement to libcurl for those systems that don't have one. Now it turns out
the curl application needs such a function too to make the support complete...

* How do I suggest we solve this?

I'll introduce functions in the library with a new prefix: 'curlx_'. They will
be provided as separate source files without any hard relations to the rest of
libcurl. They will be possible to compile for the app as well, thus it won't
need to duplicate the source code (only duplicate the compiled output).

I'm thinking about moving such generic functions' source files to a separate
directory (or possibly by using a special prefix or something), but I'll start
with just officially declaring a few functions and header files to be of this
kind. curlx_strtoll() being the first one out.

This is a meta-issue, yes, but I still think we should get stuff like this
sorted out as it will make future libcurls less stuffed with random functions.

On the list of functions for removal in a future libcurl v8 release enters:

  curl_getdate
  curl_getenv
  curl_mprintf (and variations)
  curl_strequal
  curl_strnequal

I suspect that very few applications use any of these. (They would then become
curlx_* versions so that the curl tool still can maintain functionality
without forcing it to have the source in two places.)

As always, I value your input!

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]