Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127292
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com> <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com> <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be> <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com> <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
 <1FD11284-D682-4CB7-893F-D74A1904610D@pmjones.io> <CAH5C8xVGDhDgLp0QWabx6BudAvRAcF9sVt+gR0R0C-bF3E1hRw@mail.gmail.com>
 <A465491B-0F03-46D4-AE10-550DF336FDE8@pmjones.io> <CAH5C8xXjKb_44QqH9+G5LifbDwCLXq9ieisptYxqBy_XsJUytA@mail.gmail.com>
 <1A7E42FA-27EA-404B-85EF-25190AFFDE79@pmjones.io>
In-Reply-To: <1A7E42FA-27EA-404B-85EF-25190AFFDE79@pmjones.io>
Date: Mon, 5 May 2025 23:32:33 +0200
Message-ID: <CAH5C8xX=wFeVudTBVqAYA0mDHP3qY_go6YbgM-iJq4qbVGcMfw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: "Paul M. Jones" <pmjones@pmjones.io>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000092458806346a3d1b"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--00000000000092458806346a3d1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

I would not presume that the dedicated value objects are what "makes the
> [Rowbot] library much slower" than the RFC -- instead,

my first intuition is that the *parsing* operations are slower in userland
> than in C, and are primarily responsible for the comparative slowness.

Speedwise, creation of multiple objects from the parsed results would be a
> rounding error compared to the parsing itself.
>

Yes, I may have arrived at the wrong conclusion based on the right factors:
the Rowbot library uses objects for not just representing the components,
but even the parser states and other things, whereas in the C library,
parsing is just an enormous switch-case. I know that instantiating objects
doesn't
take a lot of time, but I guess the performance difference between a very
nicely written, full OO PHP code and an optimized C code will start to be
very much noticeable with a larger iteration number. Anyway, I shouldn't
have tried to compare the performance of the two solutions, since it's
really not
a fair comparison, and not the main point.

I think that's fair. The main thing that stands out to me is not the
> Scheme, Host, etc. value objects, but that the RFC presents no UrlRecord =
--

which is very definitely part the WHATWG-URL specification. That is, from
> reading the spec, I'd expect to see a UrlRecord, and a Url composed from =
it.
>

I believe the UrlRecord is a minor detail of the specification that is
possible to omit without sacrificing anything useful: having a record in
addition
to the URL class doesn't bring much to the table. For similar reasons, the
RFC doesn't implement the WHATWG getters either, and the pure
components are exposed instead (the "Component retrieval" section writes
about this). So the RFC does not entirely implement the API prescribed by
the
WHATWG URL spec, however it accurately follows the parsing details -- which
is the main benefit in my opinion.


> Meanwhile, AFAICT, neither Rowbot nor the RFC provide a percent *en*codin=
g
> mechanism, for consumers to put together properly-encoded values.

Have I missed it in the RFC, or is it somehow not necessary, or something
> else?
>

Percent-encoding is usually automatically done for WHATWG (even if soft
errors may be triggered during the process), so it was not a top priority
for me just yet.
But I definitely want to include some sort of percent-encoding support in
the followup I plan. But in any case, thanks for raising awareness of this
topic.

Because it is part of the WHATWG-URL spec, I think it deserves first-class
> treatment in this RFC ...
>

Having yet another class in the proposal would open the possibility for a
whole lot of new discussion. We should draw the line somewhere in order not
to waste everyone's time, or the PHPFoundation's budget any longer, should
the RFC fail for any reason. And I just draw the line here, since it's a
nice to have
feature, and we have a meaningful set of functionality even without it.


> Which leads to my last point: I would really like to see at least two
> separate RFCs here. They be a lot easier to review and critique that way:
>
> - one for dealing with URIs as they exist now, especially one that the
> honors the ways-of-working that exist in userland; and,
> - one for dealing with WHATWG-URL in its entirety, with all its
> differences (some subtle, some not) from URIs.
>
> I can see arguments for either one being the "base" on which the other
> would build.
>

I may have agreed to pursue two separate RFCs a few months earlier, but not
anymore, around the very end. Although I should mention that the original
RFC tried to deal with WHATWG URLs only, RFC 3986 URIs were added later,
due to public demand. Possibly I should have stepped in around the time
when I included RFC 3986 support. However, I have to mention that working
on both specifications parallelly helped me understand a lot of the subtle
differences between the two specifications, and after bringing
these differences to the surface, the final API design could reflect and
tackle them.

Regards,
M=C3=A1t=C3=A9

--00000000000092458806346a3d1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi Paul,</div><div dir=
=3D"ltr"><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
I would not presume that the dedicated value objects are what &quot;makes t=
he [Rowbot] library much slower&quot; than the RFC -- instead,=C2=A0</block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">my first intuition =
is that the *parsing* operations are slower in userland than in C, and are =
primarily responsible for the comparative slowness.=C2=A0</blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Speedwise, creation of multipl=
e objects from the parsed results would be a rounding error compared to the=
 parsing itself.<br></blockquote><div><br></div><div>Yes, I may have arrive=
d at the wrong conclusion based on the right factors: the Rowbot library us=
es objects for not just representing the components,</div><div>but even the=
 parser states and other things, whereas=C2=A0in the C library, parsing is =
just an enormous switch-case. I know that instantiating objects doesn&#39;t=
</div><div>take a lot=C2=A0of time, but I guess the performance difference =
between a very nicely written, full OO PHP code and an optimized C code wil=
l start to be</div><div>very much noticeable with a larger iteration number=
. Anyway, I shouldn&#39;t have tried to compare the performance of the two =
solutions, since it&#39;s really not</div><div>a fair comparison, and not t=
he main point.</div><div><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">
I think that&#39;s fair. The main thing that stands out to me is not the Sc=
heme, Host, etc. value objects, but that the RFC presents no UrlRecord --=
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">which =
is very definitely part the WHATWG-URL specification. That is, from reading=
 the spec, I&#39;d expect to see a UrlRecord, and a Url composed from it.<b=
r></blockquote><div><br></div><div>I believe the UrlRecord is a minor detai=
l of the specification that is possible to omit without sacrificing=C2=A0an=
ything useful: having a record in addition</div><div>to the=C2=A0URL class =
doesn&#39;t bring much to the table. For similar reasons, the RFC doesn&#39=
;t implement the WHATWG getters either, and the pure</div><div>components a=
re exposed instead (the &quot;Component retrieval&quot; section writes abou=
t this). So the RFC does not entirely implement the API prescribed=C2=A0by =
the</div><div>WHATWG URL spec, however it accurately follows the parsing de=
tails -- which is the main benefit in my opinion.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
Meanwhile, AFAICT, neither Rowbot nor the RFC provide a percent *en*coding =
mechanism, for consumers to put together properly-encoded values.=C2=A0</bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Have I missed it=
 in the RFC, or is it somehow not necessary, or something else?<br></blockq=
uote><div><br></div><div>Percent-encoding is usually automatically done for=
 WHATWG (even if soft errors may be triggered during the process), so it wa=
s not a top priority for me just=C2=A0yet.</div><div>But I definitely want =
to include some sort of percent-encoding support in the followup I plan. Bu=
t in any case, thanks for raising awareness of this topic.</div><div><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">
Because it is part of the WHATWG-URL spec, I think it deserves first-class =
treatment in this RFC ...<br></blockquote><div><br></div><div>Having yet an=
other class in the proposal would open the possibility for a whole lot of n=
ew discussion. We should draw the line somewhere in order not</div><div>to =
waste everyone&#39;s=C2=A0time, or the PHPFoundation&#39;s budget any longe=
r, should the RFC fail for any=C2=A0reason. And I just draw the line here,=
=C2=A0since it&#39;s a nice=C2=A0to have</div><div>feature, and we have a m=
eaningful=C2=A0set of functionality even without it.</div><div>=C2=A0</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">
Which leads to my last point: I would really like to see at least two separ=
ate RFCs here. They be a lot easier to review and critique that way:<br>
<br>
- one for dealing with URIs as they exist now, especially one that the hono=
rs the ways-of-working that exist in userland; and,<br>
- one for dealing with WHATWG-URL in its entirety, with all its differences=
 (some subtle, some not) from URIs.<br>
<br>
I can see arguments for either one being the &quot;base&quot; on which the =
other would build.<br></blockquote><div><br></div><div>I may have agreed to=
 pursue two separate RFCs a few months earlier, but not anymore,=C2=A0aroun=
d the very end. Although I should mention that the original</div><div>RFC t=
ried to deal with WHATWG URLs only, RFC 3986 URIs were added later, due to =
public=C2=A0demand. Possibly I should have stepped in around the time</div>=
<div>when I included RFC 3986 support. However, I have to mention that work=
ing on both specifications parallelly helped me understand a lot of the sub=
tle</div><div>differences between the two specifications, and after bringin=
g these=C2=A0differences to the surface, the final API design could=C2=A0re=
flect and tackle them.</div><div><br></div><div>Regards,</div><div>M=C3=A1t=
=C3=A9</div><div><br></div></div></div>
</div>

--00000000000092458806346a3d1b--