Hi On 3/1/26 20:48, Jakub Zelenka wrote:
The policy recommends consistency with existing symbols and there are already OpenSSLCertificate, OpenSSLCertificateSigningRequest and OpenSSLAsymmetricKey. So I think we should stick with no namespace here and calls it OpenSSLSession and OpenSSLException. I will introduce that exception as I agree it makes more sense.
The policy also states:
This is a somewhat loose guideline, and applies more strongly to functions than classes.
I don't feel strongly about the OpenSSLSession class, but I feel strongly about the exception hierarchy:
It should immediately be introduced into the namespace, because the exception hierarchy is relevant to the entire extension (e.g. also to newly namespaced bits) and namespacing it later will become messy.
However since the OpenSSLSession class will also be an entirely new API with proper methods instead of just an opaque resource object, it is more likely to be directly used by developers. So putting it into a namespace to follow the “latest best practices” there still makes sense to me, even if it introduces some inconsistency. You always need to start with *something*, otherwise you're never going to to the migration for existing extensions.
Best regards Tim Düsterhus
