cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: extract max keepalive requests configuration using a discovery loop

From: Roberto Nibali <ratz_at_drugphish.ch>
Date: Thu, 29 Sep 2005 15:29:38 +0200

>> From a OOA design point of view. I might be wrong in how people peruse
>> libcurl but if you write your application using functions or methods
>> you most certainly pass the CURL handle as a parameter to the function.
>
> I don't know either, but I try to keep an open mind and not make any
> conclusions. We define how the API works, the app authors decide how to
> use the API.

Well, not quite. I seriously hope the people use the API as defined and
documented, everything else would be out of specification and could bite
you in your butt.

> Perhaps it would be nice to some. But like everything in this world,
> this is double edged. There is also the other end: the code gets bigger
> (both source and binary), it gets more to document, it gets more to test
> and it adds more things that have to be done for every new future option
> we add.

I don't buy the code gets bigger argument, you could always make this a
configurable option. Besides, it probably only adds a couple of hundred
bytes to the bss section. I'd be more than happy to write the document
using a well placed sed on the curl_easy_setopt() documentation :). 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.

So, what about putting it into curl_easy_getinfo()? Although
semantically this does not fit, it would be less of a code bloat, maybe.

> All this for a feature that "would be nice" and that obviously thousands
> of users so far have not considered a big issue.

I would love to hear what other authors of applications using libcurl
think about this.

> In the end, this makes such a feature not so nice to me.

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 think I do. I just don't think adding such a function is worth the
> burdon it comes with.

If you call it a burden, then not ;).

Cheers,
Roberto Nibali, ratz

-- 
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------
Received on 2005-09-29