On Feb 18, 2025, at 08:43, Kévin Dunglas <ke...@dunglas.fr> wrote:


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/InputStream.html / https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/OutputStream.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évin Dunglas



This streamlined and narrower-scoped approach gets a big +1 from me.

I also really like the idea of a unified compression OO API, as future scope.

Cheers,
Ben

Reply via email to