Hi
Am 2025-02-18 13:46, schrieb Jordi Boggiano:
My question is: Why? Please also have a look at:
https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces.
Instead of creating a top-level namespace for both Brotli and Zstd it
would probably make sense to create a new “Compression” extension that
could also include a new and improved gzip (and bz2) API as a
follow-up. The new ext/random could probably serve as an API example.
The main reason why is that we were mostly trying to keep this simple,
so the RFC is simply what is currently in the extensions. But I fully
agree with you, this doesn't look like the cleanest API, and it might
be a good opportunity to clean things up.
I assumed as much, but indeed a “blessed” implementation in core should
be held to a higher standard and ideally make use of the latest and
greatest language features to create an API that is a joy to use. As an
example, the Brotli compression mode should likely be
namespace Compression\Brotli;
enum Mode {
case Generic;
case Text;
case Font;
}
or something like that.
I guess we'll go back to the drawing board and try to come up with an
API proposal that fits in better.
I would also suggest critically questioning whether all the features
provided by the existing extensions are necessary. As an example, I'm
not sure if the implicit output compression INI settings are actually
necessary nowadays. The common webservers / FastCGI gateways will
perform dynamic compression of FastCGI responses by default, making the
implementation redundant and possibly requiring the user to configure
compression in two places. And modern frameworks likely want to have
strict control about the exact output as well.
Best regards
Tim Düsterhus
