On Wed, 16 Dec 2009, Philip A. Prindeville wrote:

> It's also easier to deploy new settings if they are only turned on in one
> place, rather than in $HOME/.curlrc for hundreds or thousands of users.
>
> Lastly, there's the open question of whether this should apply to just Curl
> or to libcurl... there's a number of 3rd party software packages that link
> to libcurl (such as Asterisk) and they would need a mechanism for importing
> these same defaults. A site-wide defaults file solves the problem of
> rolling out new options when libcurl.so gets released, without having to
> edit, re-compile, repackage, redistribute, and reinstall all of the software
> packages that link with libcurl.so.

This is a big question that isn't easy to address and work on from our side
alone. I can't help but to also think that the reason nobody has brought this
up before is that others too see the problems and quite possibly also that not
that many see any major benefits.

I'd like to split the issue into curl vs libcurl. And then I'll push over the
discussion about a curl tool site-wide config to the curl-users list. For
curl, the issues are quite different and much easier to solve.

Regarding introducing a site-wide config to libcurl. Here's a few items I
could think of we need to consider:

  o Naming. Where does the config reside? While I would assume just about all
    distros and OSes would pick their own place, we'd have to set a default.

  o When does it load. I figure curl_global_init() would have to be the
    funcion that loads the file into a memory buffer. Since the global context
    is global, it might not be suitable to do the parsing of the config since
    it could be used to have more special configs than just for all
    connections. Also, since we only set options for libcurl on a per-handle
    basis we don't know if specific requests want to run affected or unaffected
    of the site-wide config until later so we can't do anything until the
    specific transfers get setup.

    I guess that with a config file support, we would also like to allow a set
    specific config file to read and that can also only be done at *_perform()
    time.

  o Parsing. We don't have any config parsing or setting code in libcurl today
    and it would have to be introduced for this purpose. It would have to get
    done at *_perform() basically since we need local options set first before
    we read the site config, like to know if we should care about it at all.

  o Syntax. Then there's the whole issue about how the config should look like
    and what it should be able to control and with what flexibility. Like
    should it be able to specify options for particular target sites and
    protocols? Without a fair set of users and use-cases we can basically only
    guess what people might want, and guessing that much tend to miss or just
    get it wrong to a rather large extent. Is there an existing syntax used
    somewhere else we could base it on? (And now I just cross my fingers nobody
    will mention the X*L word...)

After all, a major app like Asterisk could just provide its own config file
and set its own libcurl options in the first place.

But I'll be clear: I don't dismiss the idea. I just think it's a rather large
question and feature and it needs to be thought through and discussed before
we take it anywhere.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html