Hey, On Tue, 18 Feb 2025, 13:04 Tim Düsterhus, <t...@bastelstu.be> wrote:
> 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 I've tried to reply twice, but you guys are too quick! :-) @Jordi, great initiative on modern stuff. 1. Apart from asset compression can you think of other practical use cases where Brotli and such would be useful? Helps to understand bigger picture too than webserver compression of assets and similar. 2. Introducing this into core - in reality in 2025 there are more junior devs (or just general people using abstractions) than ever before. The nature of tech evolution. This isn't a bad thing, because it means more users, but the negative side effect is that people are allergic to installing extensions, in general, because it's not a simple "turnkey solution" and as such people tend to avoid using latest things or just use another programming language that it just "ships with" Thus including this stuff into core is more important and relevant these days, than ever before. @Tim - I really like your thinking of making a combined "standard" compression extension. It will make maintenance and upgrades more consolidated, and a more consistent API across existing and upcoming compression libs. Such as functional vs OOP and the OOP layout/structure of things. It also means less extensions to install, as time goes on, when we add new ones to keep PHP uptodate, looping back to my previous point of why avoiding bringing more extensions for end users to install is important. Having spent many years in PHP-FIG and lots of effort trying to build one "standard" for lots of implementations that differ. I just want to point out that I think we should avoid trying to make a standard design for all the Compression drivers and features and instead agree that things (Enums?) will and should differ from drive too driver and that'd okay. Maybe this is a bit of a new side topic from Jordi's Brotli proposal, but I think it's still relevant to keep in scope for the next steps. Thanks, Paul > >> 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 >
