On Tue, 16 Oct 2001, Sterling Hughes wrote:

> > I would personally like to see an "advanced" more low level API, but I have
> > no illusions that I can pull this off by myself so until someone steps
> > forward to participate on this, I am not exploring those possibilities.
>
> I'll also volunteer to help with sub-tasks, however, I'm not sure
> enough in the current cURL source to know exactly what needs to be
> done...

Well, let's take one step at a time then. We could start with designing how a
working API could look like.

> Sounds good, personally I'm for something like the following
> interface:
>
> CURL *cp;
> char buf[1024];
> size_t nbytes;
>
> cp = curl_init();
> curl_setopt(cp, CURLOPT_URL, "http://www.someurl.com");
>
> // curl_select(cp, read,...);
>
> curl_connect(cp);
> while (!curl_is_eof(cp)) {
> nbytes = curl_read(cp, buf, 1024);
> if (nbytes == -1) {
> fprintf(stderr, "AHHHHH there was a read error %s",
> curl_error(cp));
> return -1;
> }
>
> puts(buf);
> }
>
> curl_close(cp);
> curl_free(cp);

... ok, diving into the heat right away, are we? ;-)

Some things to consider, taken off the top of my head:

 How do we support such a beast such as HTTP posting, where we must be able
 to send and receive data simultanously? Hm, perhaps not, as the post form
 is setup prior to the actual operation and then only the read() would be
 driven by the app...

 How do we signal/offer the headers of the particular document we're getting?
 I figure we shouldn't just return a block of data, we should somehow also
 return a handle that could be used by the application to query on
 specific details on the data (like if it is a header etc).

 Will these functions have any particular (non-)blocking requirements? The
 connect call would risk taking a long time if it would continue doing
 synchronous name lookups etc.

 How would we support asking for passwords that today is set with a password
 callback?

We should write down the functions, document their expected behavior and we
could try writing some faked implementation of clients using it. Then it'll
be easier to implement the API. IMHO.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/