Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130252
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
 <2d741c45-9c92-4404-a0d5-02bf26a557b1@bastelstu.be> <CAEKnhAFndXvd=YKFx5aN8yH=kw2NJ5NW_+mOX8OxUYfOYOpapw@mail.gmail.com>
 <cfbcf25d43c6235688c25792a9857c4b@bastelstu.be> <CAEKnhAHy3Zr5wnqoX4Z7zP=eQ8CfK9G7i6tq_9SV9z4NC+fJiw@mail.gmail.com>
 <c24dda3b-109c-4cd5-b578-f119d7ecccbc@bastelstu.be> <CAEKnhAH6ddjL3_UWtn8oBPAny41zPOqLe26ufSEckDarvbx1oA@mail.gmail.com>
In-Reply-To: <CAEKnhAH6ddjL3_UWtn8oBPAny41zPOqLe26ufSEckDarvbx1oA@mail.gmail.com>
Date: Wed, 4 Mar 2026 23:11:43 +0100
Message-ID: <CAEKnhAESK8cuD4dp29miLN41hD13e-6vR8X2pOM5SE_SU+igLg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] TLS Session Resumption Support for Streams
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008f925f064c3a1b3e"
From: bukka@php.net (Jakub Zelenka)

--0000000000008f925f064c3a1b3e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Mar 1, 2026 at 9:16=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> On Sun, Mar 1, 2026 at 9:05=E2=80=AFPM Tim D=C3=BCsterhus <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 her=
e
>> 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

--0000000000008f925f064c3a1b3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 1, 2026 at 9:16=
=E2=80=AFPM Jakub Zelenka &lt;<a href=3D"mailto:bukka@php.net">bukka@php.ne=
t</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Sun, Mar 1, 2026 at 9:05=E2=80=AFPM Tim D=C3=
=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be" target=3D"_blank">tim@ba=
stelstu.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hi<br>
<br>
On 3/1/26 20:48, Jakub Zelenka wrote:<br>
&gt; The policy recommends consistency with existing symbols and there are<=
br>
&gt; already OpenSSLCertificate, OpenSSLCertificateSigningRequest and<br>
&gt; OpenSSLAsymmetricKey. So I think we should stick with no namespace her=
e and<br>
&gt; calls it OpenSSLSession and OpenSSLException. I will introduce that<br=
>
&gt; exception as I agree it makes more sense.<br>
<br>
The policy also states:<br>
<br>
&gt; This is a somewhat loose guideline, and applies more strongly to funct=
ions than classes.<br>
<br>
I don&#39;t feel strongly about the OpenSSLSession class, but I feel <br>
strongly about the exception hierarchy:<br>
<br>
It should immediately be introduced into the namespace, because the <br>
exception hierarchy is relevant to the entire extension (e.g. also to <br>
newly namespaced bits) and namespacing it later will become messy.<br><br><=
/blockquote><div><br></div><div>&gt;=C2=A0=C2=A0existing extensions SHOULD =
follow the rules for newly introduced exceptions, but MAY diverge for consi=
stency with existing symbols.</div><div><br></div><div>The consistency is t=
he key here. I really don&#39;t like introducing a namespace and have some =
classes in it and some not - that&#39;s really not a consistency then IMO.<=
/div></div></div></blockquote><div><br></div><div>So I thought about this a=
nd it&#39;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 w=
hat others prefer. I just did the RFC update and implementation. I introduc=
ed OpenSSLException for now but if the secondary vote results in namespace,=
 I will change it before merging. In addition I also fixed the serialize an=
d export / import to default to PEM which is better for PHP and more consis=
tent with other functions.</div><div><br></div><div>Kind regards,</div><div=
><br></div><div>Jakub</div></div></div>

--0000000000008f925f064c3a1b3e--