Curl support RFC

[Jonas Drewsen]

On 11/03/11 22.21, Jesse Phillips wrote:
> I'll make some comments on the API. Do we have to choose Http/Ftp...? The URI already contains this, I could see being able to specifically request one or the other for performance or so www.google.com works.

That is a good question.

The problem with creating a grand unified Curl class that does it all is 
that each protocol supports different things ie. http supports cookie 
handling and http redirection, ftp supports passive/active mode and dir 
listings and so on.

I think it would confuse the user of the API if e.g. he were allowed to 
set cookies on his ftp request.

The protocols supported (Http, Ftp,... classes) do have a base class 
Protocol that implements common things like timouts etc.


> And what about properties? They tend to be very nice instead of set methods. examples below.

Actually I thought off this and went the usual C++ way of _not_ using 
public properties but use accessor methods. Is public properties 
accepted as "the D way" and if so what about the usual reasons about why 
you should use accessor methods (like encapsulation and tolerance to 
future changes to the API)?

I do like the shorter onHeader/onContent much better though :)

/Jonas

> Jonas Drewsen Wrote:
>
>> //
>> // Simple HTTP GET with sane defaults
>> // provides the .content, .headers and .status
>> //
>> writeln( Http.get("http://www.google.com").content );
>>
>> //
>> // GET with custom data receiver delegates
>> //
>> Http http = new Http("http://www.google.dk");
>> http.setReceiveHeaderCallback( (string key, string value) {
>> 	writeln(key ~ ":" ~ value);
>> } );
>> http.setReceiveCallback( (string data) { /* drop */ } );
>> http.perform;
>
> http.onHeader = (string key, string value) {...};
> http.onContent = (string data) { ... };
> http.perform();