On Sat, 9 Sep 2006, Christian Grade wrote:

> I don't know anything about the impact of an implementation of http
> pipelining when it comes to reacting to unexpected, undesirable server
> responses.

It doesn't change that much, but of course some requests may need to get
re-sent when in a non-piped situation they might not have had to.

> I quoted the one responsible on "major overhaul". It sounded as if
> everything is going to change, mankind being on the verge of extinction.
> Well, so it's just a bit more than refactoring.

That one was me and the added pipelining support has changed lots of
internals. If you check my commit from a few days ago you should see that. The
unified patch was some 250K.

This change is now in CVS HEAD.

> There *might* be a good reason not to take the approach of using keys
> instead of handles themselves but I currently don't see why not to make use
> of this abstraction.

Can you please give me a real use-case example where such an API would be used
and where it would actually add something useful to the application using
libcurl?

> Identifying data only by an 'easy handle' seems a shortsighted approach
> since all transfer-relevant data continues to exist in an application, but
> this does not hold true for the association between 'socket' and a
> short-termed 'currently transferring'.

First, consider that libcurl works and has worked for many years, long before
you entered this with your arrogant attitude. Then, understand that libcurl is
used in a large amount of different use cases, where most of them certainly is
not like yours.

Even if the libcurl API doesn't work the way you would have designed it, it
doesn't meant it is bad you know.

Calling things you clearly don't understand for "shortsighted" is nothing but
stupid and I will drop this whole thread soon if you don't stop your insults
in every single mail.

libcurl is open source and a community effort that have developed over many
years. You're free and even encouraged to help us improve it. I repeatedly ask
you to send in your patches showing us exactly how you would improve it.

> And in a multi-threaded application, everything is modeled around shared
> entities.

The multi interface is not designed to be used multi-threaded. On the
contrary, it is explicitly designed to be used single-threaded but still allow
large amounts of simultanoues transfers.

> It's so obvious: if a transfer is enqueued, waiting for actual transfer,
> thus no handle associated with it yet, only thing you can grab entities with
> is a key.

In libcurl you don't have an "enqueued" transfer like that, so I'm not sure
what you're talking about.

> A consequence is the need to make those entities local to 'a' or 'the'
> multi-interface. This might help to understand why I consider the maximum
> number of current 'easy handles' in use pretty constant.

Sorry. I don't understand it at all.

> In my case, I don't see the scenario "I need to stream three files off the
> net onto my BSD box using only one console command instead of the usual
> three."

And how is that relevant to this discussion?

> Of course libcurl can support the three scenarios I mentioned fine ("file",
> "continuous buffer", "chunked buffer"). One still needs to implement
> everything else (e.g. chunk collector class for memory management).

Yes, libcurl only does the transfers. You do the rest.

> The next natural advance of an interface includes simplification while
> maintaining versatility.

In my view, that is what libcurl does.

> "Name user interface thingies according to the perception of the user, not
> the lib developer, be unambiguous and precise." -- unknown
> e.g.: CURLOPT_ASSOCIATE_DATA, void*

Yes, you could've argued that here on the list back when we added the option
and it is very possible that we would've listened to that argument then. Now,
it is a bit too late. Besides, these options are not "user interface
thingies".

And you're the first person ever to complain about this (too).

> setopt( hSingle, CURLOPT_GIMME_REDIRECTIONS, &first_node );

?

I read over my reply here and I can't help asking myself: what do you want?
What is the purpose of this? It seems you're swinging randomly on various
things in libcurl you dislike or think is bad, but I have no idea why you do
this or what the greater purpose of your slugging is.

I won't reply to further emails in this style unless you present something
"real".

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