Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127293
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
In-Reply-To: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
Date: Mon, 5 May 2025 23:36:05 +0200
Message-ID: <CAH5C8xVquAMhQyrmnsBhnHtVrTpvC1+iW=pGf7EM0sHAGuAXeA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000039cff406346a4a02"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000039cff406346a4a02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Internals,

After more than a hundred emails refining even the tiniest details, we have
reached a point where I'd like to call for a vote.
I know that the new API still doesn't support many use-cases, it still has
missing pieces, but now it includes a cohesive set
of functionality that could be a very useful basic building block for most
people.

That said, I don't intend to change anything about the RFC anymore, unless
there's still some factual error in it. There are a lot of
possibilities how such a large API can look like, and this RFC approaches
the problem the way it is currently described,
and not in any other way.

So unless some very serious issues arise, I'm going to start the vote on
8th May, possibly in the morning (according to UTC).

Regards,
M=C3=A1t=C3=A9

--00000000000039cff406346a4a02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello Internals,</div><d=
iv dir=3D"ltr"><br></div><div>After more than a hundred emails refining eve=
n the tiniest details, we have reached a point where I&#39;d like to call f=
or a vote.</div><div>I know that the new API still doesn&#39;t support many=
 use-cases, it still has missing pieces, but now it includes a cohesive set=
</div><div>of functionality that could be a very useful basic building bloc=
k for most people.</div><div><br></div><div>That said, I don&#39;t intend t=
o change anything about the RFC anymore, unless there&#39;s still some fact=
ual error in it. There are a lot of</div><div>possibilities how=C2=A0such a=
 large API can look like, and this RFC approaches the problem the way it=C2=
=A0is currently described,</div><div>and not in any=C2=A0other way.</div><d=
iv><br></div><div>So unless some very serious issues arise, I&#39;m going t=
o start the vote on 8th May, possibly in the morning (according to UTC).</d=
iv><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div></div>
</div>

--00000000000039cff406346a4a02--