Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126447
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 18 Feb 2025 14:02:00 +0100
To: Jordi Boggiano <j.boggiano@seld.be>
Cc: Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli)
In-Reply-To: <5fa7423e-d723-451e-a73d-a98512a6ca96@seld.be>
References: <528e16e1-1fb3-448a-b187-7cc84e1bcc4a@seld.be>
 <b24ce14ffc9382ef7784570fcdcaadb7@bastelstu.be>
 <5fa7423e-d723-451e-a73d-a98512a6ca96@seld.be>
Message-ID: <8256945f09944cb16db34fd8139da63e@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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