cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: "easier" interface (was: Redirect Ouput to a variable in dll)

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Tue, 8 May 2012 08:42:48 +0200 (CEST)

On Mon, 7 May 2012, Andrei Cipu wrote:

>> I would object to it violently. You need to produce MUCH better arguments
>> why getinmemory.c is not the suitable way for you (as that is pretty much
>> exactly what PHP/CURL's RETURNTRANSFER does).
>
> Well, I would also see such a function as a wrapper over getinmemory.c The
> main difference would be that the code would be in the library, thus freeing
> the client application of memory management involved in reassembling the
> buffer.

I understand that, but as I see it is just one way out of very many different
ways to receive data and I don't particularly understand why we need a
shortcut for this solution. The getinmemory.c source code is not complicated,
big or hard to understand.

> Is your objection linked to the fact that such a function would divert from
> the rule that the return value is the error code or are there other reasons
> too?

We can't change curl_easy_perform() into returning anything else so no, that's
not my objection since you would have to come up with a different
API/prototype for it. (And in general I'm against adding new functions unless
there's a really good reason for them.)

This seemingly small idea can have a potentially large impact on all sorts of
APIs and code without any significant benefit. Like for example how would the
application free the buffer in which the response was received? What if the
application also wants response headers, would they be returned in a separate
buffer? What if the server returns a never-ending response-body?

It is also a somewhat drastic step away from how libcurl delivers data to the
application and it would introduce an exception that I don't like, "libcurl
provides data this way, EXCEPT if you use this option then it does this other
way".

> Perhaps libcurl could have yet another, "easier" or "super easy" interface
> that could take the best of what various wrappers offer?

Why? What would we gain by offering such an API? IMO libcurl already provides
a very easy API for the easy cases. I don't think we need to make it even
simpler!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-08