> 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.
