Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129312
Precedence: list
MIME-Version: 1.0 (Mimestream 1.8.3)
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
In-Reply-To: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
Date: Wed, 19 Nov 2025 10:58:21 -0600
Message-ID: <CAEPJdun7x=pWgOW9kQ+Ai0b0C7bAaFcfq2axo7_MXa6nJOneiA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f1aefe0643f57c54"
From: kontakt@beberlei.de (=?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?=)

--000000000000f1aefe0643f57c54
Content-Type: text/plain; charset="UTF-8"

Am 19.11.2025, 13:35:13 schrieb Edmond Dantes <edmond.ht@gmail.com>:

> Hello all
>
> According to all previous discussions, version 1.6 of this RFC has
> been prepared and is now being submitted for a vote:
>
> Voting Page: https://wiki.php.net/rfc/true_async/voting
> RFC https://wiki.php.net/rfc/true_async
>

voted No soley because of the API design problems that Tim mentioned and
needs to be addressed before voting.

Its not a vote on the merits of the RFC in general.


> The vote officially starts tomorrow, as previously announced.
>
> For version 1.6 the following important change was made:
> All input/output functions are now bound by the shared requirement of
> being non-blocking with respect to the process. However, the specific
> behavior of each function may (optionally) be defined in separate
> RFCs.
>
> Thus, I/O functions themselves are not part of this RFC, but the main
> RFC defines the general way in which they must operate. Thus (as I see
> it), the RFC achieves a balance between cohesion and separation of
> concerns.
>
> Since the discussion period has ended, I will not be engaging in
> further debate (except regarding the voting process itself). If you
> have any questions for me of any kind, you may ask them either in a
> separate thread or privately. (This also means that I will not be
> answering RFC-related questions in this thread). I will be glad to
> hear your opinions and feedback. I wish all participants the best of
> luck.
>
> ---
> Best Regards, Ed
>

--000000000000f1aefe0643f57c54
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><body><div dir=3D"ltr"><br></div>
<div class=3D"gmail_quote">
    <div dir=3D"ltr" class=3D"gmail_attr">Am 19.11.2025, 13:35:13 schrieb E=
dmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond.ht@gmail.com=
</a>&gt;:<br></div>
    <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" type=3D"cite">
       =20
<div>
<div>
    Hello all<br><br>According to all previous discussions, version 1.6 of =
this RFC has<br>been prepared and is now being submitted for a vote:<br><br=
>Voting Page: <a href=3D"https://wiki.php.net/rfc/true_async/voting">https:=
//wiki.php.net/rfc/true_async/voting</a><br>RFC <a href=3D"https://wiki.php=
.net/rfc/true_async">https://wiki.php.net/rfc/true_async</a><br></div></div=
></blockquote><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e" dir=3D"ltr">voted No soley because of the API design problems that Tim m=
entioned and needs to be addressed before voting.</div><div class=3D"gmail_=
quote" dir=3D"ltr"><br></div><div class=3D"gmail_quote" dir=3D"ltr">Its not=
 a vote on the merits of the RFC in general.</div><br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" type=3D"cite"><div><div><br>The vote officiall=
y starts tomorrow, as previously announced.<br><br>For version 1.6 the foll=
owing important change was made:<br>All input/output functions are now boun=
d by the shared requirement of<br>being non-blocking with respect to the pr=
ocess. However, the specific<br>behavior of each function may (optionally) =
be defined in separate<br>RFCs.<br><br>Thus, I/O functions themselves are n=
ot part of this RFC, but the main<br>RFC defines the general way in which t=
hey must operate. Thus (as I see<br>it), the RFC achieves a balance between=
 cohesion and separation of<br>concerns.<br><br>Since the discussion period=
 has ended, I will not be engaging in<br>further debate (except regarding t=
he voting process itself). If you<br>have any questions for me of any kind,=
 you may ask them either in a<br>separate thread or privately. (This also m=
eans that I will not be<br>answering RFC-related questions in this thread).=
 I will be glad to<br>hear your opinions and feedback. I wish all participa=
nts the best of<br>luck.<br><br>---<br>Best Regards, Ed<br>
</div>
</div>
    </blockquote>
</div></body></html>

--000000000000f1aefe0643f57c54--