On Tue, 29 Aug 2006, Mohun Biswas wrote:

>> Can't you store the errorbuffer pointer in a private struct and link it to
>> the handle with CURLOPT_PRIVATE instead?
>
> Well, yes, but let me recast the issue. On further thought, this is the sort
> of thing that belongs in a curl_easy_getopt() function, not
> curl_easy_getinfo.

Quite true. CURLOPT_PRIVATE was mostly added to curl_easy_getinfo() to save us
from having to add a new function.

> So I did a little web searching and found that it's come up before (cf
> <http://curl.haxx.se/mail/lib-2005-09/0246.html>). In that thread, Daniel
> was reluctant to allow curl_easy_getopt in without a compelling argument for
> it. It seems to me that the requirement to free our own data is the
> compelling argument, because there are a number of values (URLs, error
> buffers, slists, etc) which have to be set into the easy handle with
> curl_easy_setopt and which we (API users) have the responsibility of freeing
> later, and quite possibly in a different stack frame.

I'm not convinced that is a compelling argument. You still need to know
exactly which of these values to extract and how to free each one of them,
which thus forces you to pass logic around for that and if you do that, having
the actual pointers stored too is hardly much extra work.

> So yes, we could invent our own structures containing lists of pointers to
> free and pass those around using CURLOPT_PRIVATE. But to my mind,
> CURLOPT_PRIVATE is an escape hatch analogous to eval in Perl or being able
> to insert assembler code into C code - it's good to have the option for
> special situations but if something is being done predictably and
> repeatedly, it's better to add true support for it.

I'll explain how I see it: the curl objects are opaque objects to
applications. Apps have no idea what they contain or not, and CURLOPT_PRIVATE
is just a way to attach a private sticker on this big barrel of unknown
contents. You can read that sticker again later but you still have no real
clue what the barrel contains.

I have no understanding for the parallells with eval in Perl or asm keywords
in C. I just don't see how they are anywhere close to this.

> And finally, I find the argument made in the referenced thread persuasive
> too. It is that a curl easy handle is basically an object with a bunch of
> attributes. The great majority of the SW world has come to agree that the
> setter/getter paradigm is valuable, so what's the argument for libcurl
> offering setters but no equivalent getters? We can always keep track of the
> data we set into the object but that basically means two copies with all the
> opportunities for skew and added complexity that entails.

So then you're now saying we should allow some 135 "attributes" to be readable
from the easy handle? What good would that bring the majority of libcurl
users?

I'm still reluctant to add things to libcurl that

  1 - easily can be provided and done by the application itself and
  2 - that won't used by most libcurl applications and
  3 - that will grow the library if done "right"

Of course the discussion is what features that would fit this description and
what features that don't.

In general, when I'm leaning towards a 'no' for including something I want to
see what others have to say about the suggestion and if then there's very
little support or talks about it, I consider that in favour of my way...

So, is there anyone else around with opinions in this matter? Be it in favour
or against, I'm interested.

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