On Wed, 9 Nov 2005, Cory Nelson wrote:

> the API outlined at the hiper website is far too *nix specific and
> absolutely does not complement IOCP. We all love *nix but ignoring the
> majority OS can't be done on such a widely used library.

First, I'm certainly not ruling out that we adjust the suggested API to better
fit Windows. I'm trying hard to reshuffle my old grumpy brain to come up with
ideas that will glue all these thoughts together.

That said, I think the current suggestion is still an improvement over the
"old" one, be it unix-centric or not. Since libcurl is currently already
deployed by many windows programs, I don't think we can call that "igoring the
majority OS". (Although I don't think Windows is the majority OS for libcurl.)

The API must be written to (be allowed to) work the same on *nix and Windows
for the app, but possibly use different underlying mechanisms. The whole point
of using libcurl is very often that you can do the app logic identical for
several OSes as libcurl works the same and have the same API regardless of
what OS it runs on.

Those of us who are involved in core development of libcurl only have and use
a small subset of all the platforms libcurl is used on. But we don't need to
have nor use the other platforms since working out how to do sockets on them
is fairly easy. Requiring that we should add thread or event based code for
all these 30+ operating systems is however quite a difference and simply won't
happen which then leads to an API that is much less portable than the current
one. We don't even have a test suite that runs on Windows today.

Taken all this into account, I believe the proper way is then to provide an
API that _might_ use threads and have the internal libcurl backend make the
decision...

I think I have an idea slowly growing in my head on an approach. I'll post
that in a separate mail in a short while.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html