Re: [RFC] Modern Compression (zstd, brotli)
| From: | Ayesh Karunaratne | Date: | Tue, 18 Feb 2025 15:11:55 +0000 |
| Subject: | Re: [RFC] Modern Compression (zstd, brotli) | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126451@lists.php.net to get a copy of this message | ||
> 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
> 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.
This will be great, and existing libraries that use stream wrappers
will automatically get brotli and zstd support too.
> ... [snip] which we urgently need to support natively for Composer [snip] ...
Not trying to sound discouraging at all, but I'm merely curious about
the urgency, and how Composer can make use of zstd. I get that
Composer manifest downloads could make use of zstd, but the package
download format ultimately depends on what the hosting VCS supports.
In most cases, it will be GitHub, which seems to only support zip and
tar.gz.
For
content-encoding: zstd HTTP content, Curl works great.
packagist.org seems to run on Nginx, and perhaps when used with an
zstd module (or by using something like Caddy server with zstd
built-in), we can have zstd manifest downloads even today!
Thank you.