What about adding the connection cache to the share object? The SSL
session IDs are already part of it, so adding the connection cache
seems reasonable.
I always intended to have the connection cache to also be shareable
with the share interface and I think it would fit the existing
paradigms very well.
Thank you for your answer. Maybe I will create a patch for this.
For me, that's OK. Of course, a CURLOPT_RESOLVE that only affects
one single easy handle would be better :-)
I completely understand that. I wouldn't mind introducing some sort
of mechanism that allows this.
A callback function for the name resolution would be a powerful
mechanism. Similar to CURLOPT_OPENSOCKETFUNCTION, but a bit on a
"higher level". This new callback function should be able to either
return an address, or to tell libcurl to proceed with the normal name
resolution.
I still think that libcurl's connection cache should also look at the
addresses when reusing connections. This is useful for CURLOPT_RESOLVE
(it's possible to add and remove "name to address" mappings), and it
would also be useful for the callback function proposed above.
Regards,
Michael
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
