On Thu, 29 Sep 2005, Roberto Nibali wrote:

> I don't buy the code gets bigger argument, you could always make this a
> configurable option.

Yes and no. We could, but that would make the API even harder to use than it
already is due to different built and run-time dependencies.

> Besides, it probably only adds a couple of hundred bytes to the bss section.

We currently have 124 options and I'm quite sure we'd spend more than two or
three bytes per option...

But yes, I used the size argument in a more general and philosophical view: If
we can add this feature that is "good to have" and "takes no additional space"
then we could also add feature X and Y that add other stuff that in a similar
way "take no space" and are "good to have".

By saying no to all such ideas I decrease bloat and make my own life easier
(as I tend to be the guy who maintains the code eternally after it gets added
and the person(s) who once added the code vanish). Call me a grumpy old man or
a cynic, but I've been doing this curl stuff for a while now so I think I'm
entitled to draw conclusions from past experiences.

> I'd also write a functional test application suite (which I haven't spotted
> yet for curl_easy_setopt() either), that collects all possible CURLOPT_*
> data sets.

Feel free to add tests. I don't normally prevent people from helping out! ;-)

I've spent about 15 hours spare time per week on curl for more than seven
years. I think I've written about all except 7 or 8 test cases and I've
written (or adjusted) all the test servers and written the test scripts mostly
on my own.

But yes, they still lack a lot. The *setopt() function is however used in just
about all test cases so far, so I'd say that even if there are no
function-level tests, the function is still tested.

> Well, I certainly won't argue with you over this feature, since right now to
> me libcurl does everything just perfect. Call it a tradeoff between
> uneccessary code bloat and API design beauty. I personally am a bit
> surprised that this issue hasn't come up before on this list.

I'm always interested in feedback and discussing new ideas and functions. I'm
just ventilating my own view on this, but I am truly very interested in what
opinions others may have on the idea of adding a curl_easy_getinfo()!

And yes, given enough people who argue against me with good arguments, I can
turn around and go in the direction of the crowd.

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