Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126457
Content-Type: multipart/alternative; boundary=Apple-Mail-BC87CCA0-8B25-4E1C-B939-17DDAAAC674C
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli)
Date: Tue, 18 Feb 2025 13:44:48 -0600
Message-ID: <0E1ACB43-AED4-43BD-8E6B-A86657A23A9D@benramsey.com>
References: <CADU7aosmBVHRxhjQ2=+Qk04D=7wRjASdbyMCJZethwrHZFAXGA@mail.gmail.com>
In-Reply-To: <CADU7aosmBVHRxhjQ2=+Qk04D=7wRjASdbyMCJZethwrHZFAXGA@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
From: ben@benramsey.com (Ben Ramsey)


--Apple-Mail-BC87CCA0-8B25-4E1C-B939-17DDAAAC674C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><blockquote type=3D"cite">=
On Feb 18, 2025, at 08:43, K=C3=A9vin Dunglas &lt;kevin@dunglas.fr&gt; wrote=
:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=
=BF<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi there,</div><div><br></div>Here=
 is an alternative proposal we just discussed with Jordi:<br><br>First, redu=
ce the scope of our RFC to simply add new stream wrappers for Zstandard and B=
rotli similar to those already provided for zlib: <a href=3D"https://www.php=
.net/manual/en/wrappers.compression.php">https://www.php.net/manual/en/wrapp=
ers.compression.php</a><br><br>PECL extensions for Brotli and Zstandard alre=
ady provide these wrappers, and Symfony AssetMapper uses them when available=
.<br><br>To keep things moving quickly, we won't be adding any new functions=
 or classes (perhaps just constants or enums for context options).<br><br>To=
 use these new formats, we'll need to use the low-level file/stream manipula=
tion functions. It will be possible to provide userland libraries with a mor=
e attractive API.<br><br>As a second step, in a future RFC, we could create a=
 new "Compress" interface (or class) similar to that implemented by Go's "co=
mpress" module (<a href=3D"https://pkg.go.dev/compress">https://pkg.go.dev/c=
ompress</a>) or Java's InputStream/OutputStream abstraction (<a href=3D"http=
s://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/InputStream=
.html">https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/=
InputStream.html</a> / <a href=3D"https://docs.oracle.com/en/java/javase/23/=
docs/api/java.base/java/io/OutputStream.html">https://docs.oracle.com/en/jav=
a/javase/23/docs/api/java.base/java/io/OutputStream.html</a>), which would o=
ffer a high-level API for compressing or decompressing files, and which woul=
d use stream wrappers under the hood.<br><br>In this way, we can move ahead q=
uickly and quickly provide support for Brotli and Zstandard, which we urgent=
ly need to support natively for Composer, Symfony, and probably many other p=
rojects, and we can take the time to think about a well-designed high-level A=
PI.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">--</div><div>K=C3=A9vin=
 Dunglas</div><div><br></div><div><a href=3D"https://dunglas.dev">https://du=
nglas.dev</a></div></div>
</div></blockquote><div><br></div><br><div>This streamlined and narrower-sco=
ped approach gets a big +1 from me.</div><div><br></div><div>I also really l=
ike the idea of a unified compression OO API, as future scope.</div><div><br=
></div><div>Cheers,</div><div>Ben</div><div><br></div></body></html>=

--Apple-Mail-BC87CCA0-8B25-4E1C-B939-17DDAAAC674C--