Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126448 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 5B6141A00BC for ; Tue, 18 Feb 2025 13:23:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1739884819; bh=M3IwJMSfuDmRWrRlj/OHDO9kmcijVCG7YbRgSZdODH4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=W42YvXlMuxCpTt9M7G6ownObk+mghFXmfS/nP6iBr1nQe1NS53iwYVW8oBCUL8v2/ +qS4YlTgy+UaST5bTvoEvobPlzyK4jdmGGyGx8cl+UsBYo8SlZQ4tsb7a0/LbGEQM9 mxjcRocESmM+ckMkQPBFQQGL4zoli9WfJWOZKntTmIA3gRpEOUy2R5C/NmWpg1gJj5 JBmlw6pVtxt2gwzHSNXbQqHxrKSUh2GNQtOmLotrIwkncqdjemxG0VR0a+IlgbMRz9 lxaw/2UoL+pwJ31aI1BfQRD9lzPzcY+f69OJNjPBUDz+GJoNhOP91um+B3GZOJl5mu YeZtPSI3EeOBA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 13D231801DE for ; Tue, 18 Feb 2025 13:20:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 18 Feb 2025 13:20:14 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-54529eeb38aso4163516e87.2 for ; Tue, 18 Feb 2025 05:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739884974; x=1740489774; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hdsf6YvFwXtTwG90SjxEsExc3zZo/rxs61vMgdEBJn0=; b=IEnWEf53YUT3R3KN+CSPwzBtc+qQfO+SERr1w5XjNYHPi6KIIQ7ootQgA4+d6nlB14 FK7ID6Vvkq+K2BHUeJClLL0TjIXRpuqnICzHlA7IfXbJIh7aA4qYBACZaiOBLSaRqKYE wsqrGt3t0xsirlkcAj8D6WyhZgTqwbclKnszLsDK6fdOPkG+Jl59t4nuXOTKgZJ4FyHq P/5MPMrW3yT2/BpLQgPQgGsRAcyQNQBGT4ZjaGl7HDQfZo5lKY4J438At6RK0yvDF0+A LAvSiwPqp896lf4jyuGrjps6h8U0wNk323eRMhyeeyQ3OMW5jKXqEj25NATD1+JoG56+ r1VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739884974; x=1740489774; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hdsf6YvFwXtTwG90SjxEsExc3zZo/rxs61vMgdEBJn0=; b=GyjKoH1vxG+ZV4Pga3Nrn/KUl24bDB/IwRZPd20K2lRevqw+9Sf1cKi54JktetlM1V IJpRGpbgx9Fkg+aalPvjVQIOt0/Np2a5LfKJ273SO9Yc472YDDSrZXtY4ANXm8dYH60E E+ZPYiZy/CLwvtEc/I5xkcMpaXlLrwaZNGwDU4uFMQ3jLtJGiBjk+8G30I/yO1YFi9hD v/QmLAZtHarN3s3OqFu2DMuRv9V4ScW7/b/8crDIxBkYLTfznlX5SSDRIPU5vRQDsMY9 TJ4JqIesui2lBo8zGXMQizbiGnwtF5PmvAfze9YW1GsK9jVI89frgi9sxWFafnfRYKfx bxmg== X-Forwarded-Encrypted: i=1; AJvYcCXNwy7CC+ve0cvzgHfPxaZSDl75eYF3IcjDmtdLNxTGrLmyyzUnPbNObSh4v9ACgeUBmGfkCnE9KCQ=@lists.php.net X-Gm-Message-State: AOJu0Yw0WsXqKr1z80AvvPmI51xnqw0pjRVCCXHdYVoY7T/UFznNJxDH fCYs4nS55Agwys9lTJh87vZeFDQAKrP9kkuL+a+4QWdLR1FxkUtR+lofZu59dePzmbtS58tgFH+ HbLigwQ4A9do8mY7NDG8y+3ZGgrAlgg== X-Gm-Gg: ASbGncvkD9yclf9uYGmh+juZ3Rwyx008TxzvaJzF+ULRgTki0XLKLfoqmC2oiDwmlnn L/5/ShGsGm84GMDMX/x+zXBCWKxujnOoXJB44ThNlkpzDjUGWLboZJHLcekWlvUswC3JN5QPH X-Google-Smtp-Source: AGHT+IHWH0gx6mcgKv+/EwM6lgeBPB70tO4wS6Y8PKdJRSjZFQM1u1j9K1Tsc8EPA7ObjTuzsormhcK6vmMvYUccM2U= X-Received: by 2002:a05:6512:4025:b0:540:1b07:e033 with SMTP id 2adb3069b0e04-5452fe8ebfcmr4766884e87.45.1739884973835; Tue, 18 Feb 2025 05:22:53 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <528e16e1-1fb3-448a-b187-7cc84e1bcc4a@seld.be> <5fa7423e-d723-451e-a73d-a98512a6ca96@seld.be> <8256945f09944cb16db34fd8139da63e@bastelstu.be> In-Reply-To: <8256945f09944cb16db34fd8139da63e@bastelstu.be> Date: Tue, 18 Feb 2025 13:22:41 +0000 X-Gm-Features: AWEUYZmqmuhmVtkeijaa6MGvOf2FHEBwUrTQn6yBIQwGHxV7XWUJsbmkldJ-C6Y Message-ID: Subject: Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli) To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: Jordi Boggiano , Internals Content-Type: multipart/alternative; boundary="000000000000d0ce45062e6a8901" From: dragoonis@gmail.com (Paul Dragoonis) --000000000000d0ce45062e6a8901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, On Tue, 18 Feb 2025, 13:04 Tim D=C3=BCsterhus, 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 =E2=80=9CCompression=E2=80= =9D 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 =E2=80=9Cblessed=E2=80=9D 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=C3=BCsterhus > --000000000000d0ce45062e6a8901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey,

On Tue, 18 Feb 2025, 13:04 T= im D=C3=BCsterhus, <tim@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.r= st#namespaces.
>> Instead of creating a top-level namespace for both Brotli and Zstd= it
>> would probably make sense to create a new =E2=80=9CCompression=E2= =80=9D extension that

<= div dir=3D"auto">I've tried to reply twice, but you guys are too quick!= :-)

@Jordi, great initi= ative on modern stuff.=C2=A0

1. Apart from asset compression can you think of other practical use c= ases where Brotli and such would be useful? Helps to understand bigger pict= ure too than webserver compression of assets and similar.=C2=A0

2. Introducing this into core - in = reality in 2025 there are more junior devs (or just general people using ab= stractions) than ever before. The nature of tech evolution.=C2=A0

This isn't a bad thing, becau= se it means more users, but the negative side effect is that people are all= ergic to installing extensions, in general, because it's not a simple &= quot;turnkey solution" and as such people tend to avoid using latest t= hings or just use another programming language that it just "ships wit= h"

Thus including t= his stuff into core is more important and relevant these days, than ever be= fore.



@Tim - I really like your thinking of= making a combined "standard" compression extension.=C2=A0
<= div dir=3D"auto">
It will make maintenance and u= pgrades more consolidated, and a more consistent API across existing and up= coming compression libs. Such as functional vs OOP and the OOP layout/struc= ture of things.=C2=A0

It= also means less extensions to install, as time goes on, when we add new on= es to keep PHP uptodate, looping back to my previous point of why avoiding = bringing more extensions for end users to install is important.=C2=A0
=

Having spent many years in PH= P-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 sh= ould 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.=C2=A0
Maybe this is a bit of a new side topic from Jord= i's Brotli proposal, but I think it's still relevant to keep in sco= pe for the next steps.=C2=A0

Thanks,
Paul

<= div dir=3D"auto">

>> 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 examp= le.
>>
> 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 mi= ght
> be a good opportunity to clean things up.

I assumed as much, but indeed a =E2=80=9Cblessed=E2=80=9D 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

=C2=A0 =C2=A0 =C2=A0namespace Compression\Brotli;

=C2=A0 =C2=A0 =C2=A0enum Mode {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case Generic;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case Text;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case Font;
=C2=A0 =C2=A0 =C2=A0}

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 <= br> 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=C3=BCsterhus
--000000000000d0ce45062e6a8901--