Re: [RFC] TLS Session Resumption Support for Streams

Hi, On Sun, Mar 1, 2026 at 9:16 PM Jakub Zelenka <bukka@php.net> wrote: > Hi, > > On Sun, Mar 1, 2026 at 9:05 PM Tim Düsterhus <tim@bastelstu.be> wrote: > >> 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. >> >> > > existing extensions SHOULD follow the rules for newly introduced > exceptions, but MAY diverge for consistency with existing symbols. > > The consistency is the key here. I really don't like introducing a > namespace and have some classes in it and some not - that's really not a > consistency then IMO. > So I thought about this and it's really matter of taste that should not impact the primary vote. I think it makes sense to add a secondary votes for those namings to see what others prefer. I just did the RFC update and implementation. I introduced OpenSSLException for now but if the secondary vote results in namespace, I will change it before merging. In addition I also fixed the serialize and export / import to default to PEM which is better for PHP and more consistent with other functions. Kind regards, Jakub