Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126450
Precedence: bulk
MIME-Version: 1.0
References: <528e16e1-1fb3-448a-b187-7cc84e1bcc4a@seld.be> <b24ce14ffc9382ef7784570fcdcaadb7@bastelstu.be>
 <5fa7423e-d723-451e-a73d-a98512a6ca96@seld.be> <8256945f09944cb16db34fd8139da63e@bastelstu.be>
 <CAKxcST_VfZ9YNG93BOUKQ93qGVMbDk3ttUrekws-28LvYb-a0A@mail.gmail.com> <1856be6ad7a51bf5ea56001eb719897a@bastelstu.be>
In-Reply-To: <1856be6ad7a51bf5ea56001eb719897a@bastelstu.be>
Date: Tue, 18 Feb 2025 15:41:09 +0100
Message-ID: <CADU7aosmBVHRxhjQ2=+Qk04D=7wRjASdbyMCJZethwrHZFAXGA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli)
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Paul Dragoonis <dragoonis@gmail.com>, Jordi Boggiano <j.boggiano@seld.be>, 
	Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006b8798062e6ba2a5"
From: kevin@dunglas.fr (=?UTF-8?Q?K=C3=A9vin_Dunglas?=)

--0000000000006b8798062e6ba2a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi there,

Here is an alternative proposal we just discussed with Jordi:

First, reduce the scope of our RFC to simply add new stream wrappers for
Zstandard and Brotli similar to those already provided for zlib:
https://www.php.net/manual/en/wrappers.compression.php

PECL extensions for Brotli and Zstandard already provide these wrappers,
and Symfony AssetMapper uses them when available.

To keep things moving quickly, we won't be adding any new functions or
classes (perhaps just constants or enums for context options).

To use these new formats, we'll need to use the low-level file/stream
manipulation functions. It will be possible to provide userland libraries
with a more attractive API.

As a second step, in a future RFC, we could create a new "Compress"
interface (or class) similar to that implemented by Go's "compress" module =
(
https://pkg.go.dev/compress) or Java's InputStream/OutputStream abstraction
(
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/InputS=
tream.html
/
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/Output=
Stream.html),
which would offer a high-level API for compressing or decompressing files,
and which would use stream wrappers under the hood.

In this way, we can move ahead quickly and quickly provide support for
Brotli and Zstandard, which we urgently need to support natively for
Composer, Symfony, and probably many other projects, and we can take the
time to think about a well-designed high-level API.

--
K=C3=A9vin Dunglas

https://dunglas.dev

--0000000000006b8798062e6ba2a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi there,</div><div><br></div>Here i=
s an alternative proposal we just discussed with Jordi:<br><br>First, reduc=
e the scope of our RFC to simply add new stream wrappers for Zstandard and =
Brotli similar to those already provided for zlib: <a href=3D"https://www.p=
hp.net/manual/en/wrappers.compression.php">https://www.php.net/manual/en/wr=
appers.compression.php</a><br><br>PECL extensions for Brotli and Zstandard =
already provide these wrappers, and Symfony AssetMapper uses them when avai=
lable.<br><br>To keep things moving quickly, we won&#39;t be adding any new=
 functions or classes (perhaps just constants or enums for context options)=
.<br><br>To use these new formats, we&#39;ll need to use the low-level file=
/stream manipulation functions. It will be possible to provide userland lib=
raries with a more attractive API.<br><br>As a second step, in a future RFC=
, we could create a new &quot;Compress&quot; interface (or class) similar t=
o that implemented by Go&#39;s &quot;compress&quot; module (<a href=3D"http=
s://pkg.go.dev/compress">https://pkg.go.dev/compress</a>) or Java&#39;s Inp=
utStream/OutputStream abstraction (<a href=3D"https://docs.oracle.com/en/ja=
va/javase/23/docs/api/java.base/java/io/InputStream.html">https://docs.orac=
le.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/jav=
a/io/OutputStream.html">https://docs.oracle.com/en/java/javase/23/docs/api/=
java.base/java/io/OutputStream.html</a>), which would offer a high-level AP=
I for compressing or decompressing files, and which would use stream wrappe=
rs under the hood.<br><br>In this way, we can move ahead quickly and quickl=
y provide support for Brotli and Zstandard, which we urgently need to suppo=
rt natively for Composer, Symfony, and probably many other projects, and we=
 can take the time to think about a well-designed high-level API.</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">--</div><div>K=C3=A9vin Dunglas</di=
v><div><br></div><div><a href=3D"https://dunglas.dev">https://dunglas.dev</=
a></div></div>

--0000000000006b8798062e6ba2a5--