On Tue, 15 May 2012, Steve Holme wrote:

> I've not really looked too much at what you have done with the callback but
> I think all that I would need is a way of specifying which mechanisms are
> available from the server to the callback and as the programmer which
> mechanisms I want libcurl to use for my application. Both of these arguments
> could be implemented as either a bitwise numerical value or as a list of
> mechanisms in order of preference - For example the server may tell me that
> GSSAPI is preferred, followed by NTLM and then PLAIN. I may want to tell
> libcurl that my preference is PLAIN followed by GSSAPI - and yes I would be
> mad to do this but hopefully you get my point ;-)

Joe's current suggestion doesn't really support that as libcurl doesn't offer
that functionality. The callback currently simply gets to know which method
libcurl has selected to use, based on the bitmap the application initially set
it could select from.

For HTTP we've not yet found a user who suffered from this design choice, even
though I know we've discussed it for SMTP/POP3 already - although I'll admit
I'm not sure I understand (or did I just forget?) in which situations a user
would prefer an alternative order.

This said, I really want this callback to be designed to work for virtually
any protocol libcurl supports even if the initial work is limited to HTTP. I
think you (Steve) is in a good position to provide good feedback on this since
you're one of us who'd doing the most fiddling in the POP3/SMTP areas.

I guess a step forward would be to write a test application source code using
this new API and see if it could be mapped well on FTP/IMAP/POP3/SMTP too
concept-wise.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html