Curl support RFC

[Lars T. Kyllingstad]

On Mon, 14 Mar 2011 02:36:07 -0700, Jonathan M Davis wrote:

> On Monday 14 March 2011 02:16:12 Jonas Drewsen wrote:
>> On 13/03/11 23.44, Andrei Alexandrescu wrote:
>> > On 3/11/11 9:20 AM, Jonas Drewsen wrote:
>> >> Hi,
>> >> 
>> >> So I've spent some time trying to wrap libcurl for D. There is a lot
>> >> of things that you can do with libcurl which I did not know so I'm
>> >> starting out small.
>> >> 
>> >> For now I've created all the declarations for the latest public curl
>> >> C api. I have put that in the etc.c.curl module.
>> > 
>> > Great! Could you please create a pull request for that?
>> 
>> Will do as soon as I've figured out howto create a pull request for a
>> single file in a branch. Anyone knows how to do that on github? Or
>> should I just create a pull request including the etc.curl wrapper as
>> well?
> 
> You can't. A pull request is for an entire branch. It pulls _everything_
> from that branch which differs from the one being merged with. git cares
> about commits, not files. And pulling from another repository pulls all
> of the commits which you don't have. So, if you want to do a pull
> request, you create a branch with exactly the commits that you wanted
> merged in on it. No more, no less.
> 
>> >> On top of that I've created a more D like api as seen below. This is
>> >> located in the 'etc.curl' module. What you can see below currently
>> >> works but before proceeding further down this road I would like to
>> >> get your comments on it.
>> >> 
>> >> //
>> >> // Simple HTTP GET with sane defaults // provides the .content,
>> >> .headers and .status //
>> >> writeln( Http.get("http://www.google.com").content );
>> > 
>> > Sweet. As has been discussed, often the content is not text so you
>> > may want to have content return ubyte[] and add a new property such
>> > as "textContent" or "text".
>> 
>> I've already changed it to void[] as done in the std.file module. Is
>> ubyte[] better suited?
> 
> That's debatable. Some would argue one way, some another. Personally,
> I'd argue ubyte[]. I don't like void[] one bit. Others would agree with
> me, and yet others would disagree. I don't think that there's really a
> general agreement on whether void[] or ubyte[] is better when it comes
> to reading binary data like that.

I also think ubyte[] is best, because:

1. It can be used directly.  (You can't get an element from a void[] 
array without casting it to something else first.)

2. There are no assumptions about the type of data contained in the 
array.  (char[] arrays are assumed to be UTF-8 encoded.)

3. ubyte[] arrays are (AFAIK) not scanned by the GC.  (void[] arrays may 
contain pointers and must therefore be scanned.)

I think the rule of thumb should be:  If the array contains raw data of 
unspecified type, but no pointers or references, use ubyte[].  

void[] is very useful for input parameters, however, since all arrays are 
implicitly castable to void[]:

  void writeData(void[] data) { ... }

  writeData("Hello World!");
  writeData([1, 2, 3, 4]);

-Lars