On Sun, 17 Nov 2013, Christian Grothoff wrote: > I personally think (1) is cleaner. I've attached a patch that implements > your version (1) against current Git.
I may have misunderstood my quick read of the thread but I just wanted to chirp up as I am wanting to add the something similar at some point in the future - the ability to return a list of server side capabilities for the email protocols (as reported by the CAPABILITY, CAPA and EHLO commands for IMAP, POP3 and SMTP respectively). Wouldn't option 2 be better as a) it is more in keeping with the existing API where the application owns the memory and 2) the application can then destroy it at its own leisure - potentially isn't there a scenario where libcurl destroys the connection and the application still has a pointer to the tlsinfo address that has now been destroyed? Admittedly it may be bad programming on the part of the application, as you would hope, they would not keep the pointer lying about after the curl easy handle has been destroyed but I still think this is potentially dangerous (Obviously the internal SSL handle / context is still there and shoudn't be used). At present I'm not sure whether I would use a dedicated "capability" structure for the information I want to get hold of or the existing slist - but if it is the former then I would like to follow suit (for consistency) and if it is the latter then the application owns the memory and has to call curl_slist_free_all() when it is done - a practice that libcurl programmers are familiar with ;-) I'm not too sure if this is a benefit or not, but if the memory is owned by the application (and as this structure is pretty lightweight) it also allows the application to use either stack or heap based memory as well. Additionally, is the SSL backend type needed in this structure or should we consider having it separate? Texturally that is already contained within the version information - from curl_version() - isn't it? I appreciate it may be useful for the application to obtain this without parsing the text from curl_version() but surely this isn't specific to a TLS session and perhaps a CURLINFO_SSL_BACKEND option for curl_easy_getinfo() would be better. That way the function can return a simple long containing a backend specifier and CURLINFO_TLS_SESSION could return a void* which would be the handle / context used in the session? The downside of this is that it requires two calls to curl_easy_getinfo() for the same info - but it gives the application the ability to obtain one without the other. Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
