> The 0/1/2 approach was already being used by CURLOPT_SSL_VERIFYHOST and
> CURLOPT_FTP_CREATE_MISSING_DIRS, so I just grabbed it from there.

Indeed, however I usually prefer named constant as it makes the code
more readable. This is likely something we will want to change someday
for those 2 options.

>> #define NO_DELEGATION 0L
>>
>> would make the API, documentation and code more readable.
>
> Considering all the code that includes <curl/curl.h>, I do not think
> NO_DELEGATION is a suitable name of macro to be used at global scope.
> What about the following defines?
>
> #define CURLGSSAPI_DELEGATION_NONE         0
> #define CURLGSSAPI_DELEGATION_POLICY_FLAG  (1<<0)
> #define CURLGSSAPI_DELEGATION_FLAG         (1<<1)
>
> It would be consistent with the CURLSSH_AUTH_* options.  Moreover, it allows
> to combine both flags.  Some web pages suggest that such a combination could
> be useful:
>
> http://www.h5l.org/blog/index.php/page/2/

I just mentioned some nits without thinking about the better way to
implement it (you've also seen lately how good I was at naming
stuff...). Your names are better and won't clash with anything else!

>> Maybe it could be a new feature as this is determined at compile time.
>
> What would be the use case?  We are running out of bits on CURL_VERSION_*.

I just thought it was an easy way to expose whether your library
supports GSS_C_DELEG_POLICY_FLAG or not instead of having to look into
your GSS API headers (with which you compiled the lib). There may be a
way to expose the information using some of our generated headers. It
is valuable IMHO to have a simple way of knowing that.

Thanks,
Julien

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-07-30