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
Received on 2013-11-17