On Wed, 17 Oct 2001, Daniel Stenberg wrote:

> 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...
>

   yeah, we could do that, or we could have socket flags, ie:

   if (curl_needs_write(curl_handle)) {
     write(curl_handle);
   }

    etc. This can also be accomplished by a curl_select()...

> 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).
>

    hrmm, perhaps for the advanced functions we can skip this parsing?
    \r\n\r\n isn't really that hard to look for in a c application.

> 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.
>

    hrmm, not quite sure about this, we can keep it simple at first
    then, and then expand it as needed (ie, leave a dummy flag argument
    to curl_connect())?

> How would we support asking for passwords that today is set with a password
> callback?
>
    hrmm... perhaps just call the password callback? We could also have
    a system which analyzes the transfer buffer, does any necessary
    operations with it (or decides if its suitable for just giving to
    the user) and then passes it on to the user...

> 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.
>
>

    I agree.

    -Sterling
Received on 2001-10-19