Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125658 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 6137B1A00BD for ; Mon, 23 Sep 2024 21:21:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1727126600; bh=dHQS0Bss84cDwMtGm067NfjHMdn0oVqfS4i7oLM7OmA=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ddAIpE3Lv98yyOxmhaucpLnGvsFbqsC6iAiywVe+jkC5slWYP/+5HTjEoAXvfyrJ5 7Trb5LtogJHKfhIbn1z33rS+bdSRzXwM8kRHZLjTCS42GZto0ZLnokLMddTRNMKtXK EA7DvBokMIwpMSnZEWaCFXjx/wFDxzLcZZXzjDKCk04qcJL0ljDqFg+mjQv4d1hxwO 7kEjscn124WyZlzilFvyJy9bCuC29GAzzSEzAsZxBiaagSW/Xs28yXYdN6H+60P9Wo DI0ORadcxOLaKsXYtOuP/OyZoTei4ZwSEn8FVeyrGQt69ey26gmgmgs4mMmAFqhjTN 4y2FbYCVCtwFA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9972180042 for ; Mon, 23 Sep 2024 21:23:17 +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=0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, HTTPS_HTTP_MISMATCH,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS, URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a8-smtp.messagingengine.com (fhigh-a8-smtp.messagingengine.com [103.168.172.159]) (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 ; Mon, 23 Sep 2024 21:23:17 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 2847C114025E for ; Mon, 23 Sep 2024 17:21:08 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Mon, 23 Sep 2024 17:21:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rwec.co.uk; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1727126468; x=1727212868; bh=37Pz3Z78tv BHlsssELIzfOHHGu6YQO8xkmC78X7JsL0=; b=FC/KCj/Hq3MQ3HzMena9YEtQ41 5EwqpsBd9cvP6AC8nY4pih0LbqJ/eryq38cbqJpiVm37/hzE4L/W+DuCSKPoNhgE +ve2mPH2EQPoiSkpawRxvu22Os0K5fUZEc2LdUTQPaLxtjrbnewFJ2fElN6qE0Bl cHKGG0GhdTgN/Mxoqmd1Zxc1Fvdnxhld+UIp9G+W7iyadUNHmEEtIiWKEPlQGILe oEndLbNumLn5imk6+scEkLkBggFytkM34BngoXSW8a8H4DqcoSE4U/HgzqRhy8Zi YHPpFHVl5lzQxan3wWDR5r6FEyJb3812D4Ydde/+3yLBwhHaHjrV3fqSo+sQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1727126468; x=1727212868; bh=37Pz3Z78tvBHlsssELIzfOHHGu6Y QO8xkmC78X7JsL0=; b=RMspNcptOwOsk3OAwAVhq2Y+I2GJAu/t24+bIvhhi0mC kq2Xo6+laNN//4GVR3Pd0dEKy5gKgXJZ9aJFRKC2s3bTnJliJKpo5wIW/VTN/Mm4 dtiXshkiqq8DXP6tHbWVYljbZsA6ZFXeS86xQzvES0IOnyTkngJTTERmtDkP+2ap JkxXZeBZD4efjW4mmc59FhYu8lUQd6/SdSB6zAxXYA9VHfKWep6baV0RdweI5f23 kprs+WseN1uo7+sHYx2V5THj5n/0CqLeuQFScJ7ty/ISA//TzXTKK9boftRO1j55 jg3rjoj5lvfpj/INgpUG+PtdQaMMpDap5GdgGJvWfA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudelledgudeivdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtff homhgrihhnucdlgeelmdenucfjughrpegtkfffgggfuffvfhfhjgesrgdtreertddvjeen ucfhrhhomhepfdftohifrghnucfvohhmmhhinhhsucglkffoufhorfgnfdcuoehimhhsoh hprdhphhhpsehrfigvtgdrtghordhukheqnecuggftrfgrthhtvghrnhepkefhveeikeeg ffdvvdefhfeiiefhgedvjeffleehffetueegffdtveekteffgeeinecuffhomhgrihhnpe ifohhrughprhgvshhsrdhorhhgpdhprghnthhhvghonhhsihhtvgdrihhopdhgihhthhhu sgdrtghomhdpfigrshhmvghrrdhiohdprghrtghhihhvvgdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehimhhsohhprdhphhhpsehr figvtgdrtghordhukhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: id5114917:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 23 Sep 2024 17:21:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="------------L1O0Q0ZeFp7clrxbcC7bYTse" Message-ID: <3141e1b0-d3d3-4965-b53d-9aece4f93753@rwec.co.uk> Date: Mon, 23 Sep 2024 22:21:06 +0100 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] Zephir, and other tangents To: internals@lists.php.net References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> <7EA884D2-0F37-4BF1-AC97-DB6953C944E6@automattic.com> <042AF6B3-ACAD-498E-99FA-CD7EDE8778FC@newclarity.net> Content-Language: en-GB In-Reply-To: <042AF6B3-ACAD-498E-99FA-CD7EDE8778FC@newclarity.net> From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]") This is a multi-part message in MIME format. --------------L1O0Q0ZeFp7clrxbcC7bYTse Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 23/09/2024 07:14, Mike Schinkel wrote: >> I think there's an impression that somehow by proposing that "we" add >> some complex functionality "to the language", it will suddenly >> attract developers and become stable and universally adopted; but >> it's really the other way around: once there's a mature >> implementation, and some people offering to maintain it, we can >> consider moving it to the php-src repo, if that seems beneficial. >> (And if other constraints are met, such as licensing.) > > No, it is not "the other way around," it is *both*, and > mischaracterizing it to say that the only way hosting providers will > install something is if it becomes popular dismisses the valid > approach we've been advocating for, or at least for installations on a > reasonably widespread basis (~1/3rd of hosts or more) I didn't say it needed to be *popular* before it moved to php-src, I said it needed to be *mature*. There's two reasons I think that: 1) If being "bundled with PHP" is seen by users and hosts as a stamp of approval, we don't want to put that stamp on something incomplete or insecure. Nor do we want to add code to php-src which nobody is volunteering to maintain. 2) Once an extension is moved into php-src, it is limited to PHP's release cycle - 1 feature release per year, and breaking changes only in major releases every 5 years or so. Early on in a project, it's common to make many more incremental releases, and have short deprecation periods while you experiment with the API. > What your dismissal ignores is that many hosts won't install something > unless a Framework or CMS requires or at least recommends it. And no > Framework or CMS that cares anything at all about risk management — > e.g. none with a large userbase — would require or at least recommend > an extension that is not bundled with PHP unless there is overwhelming > need for it and it targets a business vs. a technical need. From what I can see, that's not actually true. WordPress, as discussed elsewhere on this thread, has a very small list of *required* extensions, and a much longer list of "highly recommended" ones. https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions As well as "bundled with PHP" extensions such as ext/curl and ext/dom, the "highly recommended" list includes third-party / PECL extensions such as igbinary and imagick. On the hosting side, you mentioned Pantheon as an example, who I admit I hadn't heard of before. I couldn't find a concise list of supported PHP extensions, but did find this sample phpinfo() output: https://v83-php-info.pantheonsite.io/ Among the installed PECL extensions are igbinary, imagick, mongodb, msgpack, and oauth (which I note lists the version as "2.0.8dev"). Meanwhile, extensions which are bundled with PHP but *not* installed on Pantheon include ext/dba, ext/gd, ext/ffi, ext/pspell, ext/sysvmsg, ext/sysvsem, and ext/sysvshm Clearly they have a policy for which extensions to install that is not driven by whether they ship in php-src or PECL. > Then let us redirect our discussion as to whether it would be > beneficial to adopt wasmer-php into php-src repo, an objective list of > reasons it would not, if not, and an objective list of things it could > do to resolve those objections. We can certainly do that. I'm not sure if there's a strict checklist, but from my understanding, here's a few of the things we'd need to consider: Licensing - Could PHP legally distribute the extension? + Wasmer-PHP is under the MIT License, so should be fine. Stability & Maturity - Is the extension ready for production use? Is it in a state where one feature release per year will be sufficient? + Wasmer-PHP describes itself as "complete and mature", so seems promising at a glance. Portability - does the extension support the platforms PHP supports? - The compatibility table in the readme shows only Linux and Darwin on amd64, with Windows support notably lacking. I'm not sure if this would be considered a show-stopper. Dependencies - What is needed to build and run it? Does that present any licensing and portability concerns? ~ The extension itself seems to be self-contained C code (no C++, Rust, or additional build tools). I haven't looked into the runtimes that it would interface to. Maintenance - is there somebody, and ideally several people, actively responding to bug reports and compatibility updates? [See https://github.com/php/php-src/blob/master/EXTENSIONS] - This looks like a problem; the last release was over 3 years ago, and there doesn't seem to have been any activity on the public repo since. I also can't see any mention of it on the main Wasmer project site at https://wasmer.io/products/runtime or the docs at https://docs.wasmer.io/ The Wayback Machine shows the previous version of their docs listed PHP as one of  8 "language integrations", but that didn't carry across when they rewrote it last summer: http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They may be intending to come back to it later, but at the moment it seems they are not dedicating any resources to it. Regards, -- Rowan Tommins [IMSoP] --------------L1O0Q0ZeFp7clrxbcC7bYTse Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 23/09/2024 07:14, Mike Schinkel wrote:
I think there's an impression that somehow by proposing that "we" add some complex functionality "to the language", it will suddenly attract developers and become stable and universally adopted; but it's really the other way around: once there's a mature implementation, and some people offering to maintain it, we can consider moving it to the php-src repo, if that seems beneficial. (And if other constraints are met, such as licensing.)

No, it is not "the other way around," it is *both*, and mischaracterizing it to say that the only way hosting providers will install something is if it becomes popular dismisses the valid approach we've been advocating for, or at least for installations on a reasonably widespread basis (~1/3rd of hosts or more)


I didn't say it needed to be *popular* before it moved to php-src, I said it needed to be *mature*. There's two reasons I think that:

1) If being "bundled with PHP" is seen by users and hosts as a stamp of approval, we don't want to put that stamp on something incomplete or insecure. Nor do we want to add code to php-src which nobody is volunteering to maintain.

2) Once an extension is moved into php-src, it is limited to PHP's release cycle - 1 feature release per year, and breaking changes only in major releases every 5 years or so. Early on in a project, it's common to make many more incremental releases, and have short deprecation periods while you experiment with the API.



What your dismissal ignores is that many hosts won't install something unless a Framework or CMS requires or at least recommends it. And no Framework or CMS that cares anything at all about risk management — e.g. none with a large userbase — would require or at least recommend an extension that is not bundled with PHP unless there is overwhelming need for it and it targets a business vs. a technical need.


From what I can see, that's not actually true. WordPress, as discussed elsewhere on this thread, has a very small list of *required* extensions, and a much longer list of "highly recommended" ones. https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions

As well as "bundled with PHP" extensions such as ext/curl and ext/dom, the "highly recommended" list includes third-party / PECL extensions such as igbinary and imagick.


On the hosting side, you mentioned Pantheon as an example, who I admit I hadn't heard of before. I couldn't find a concise list of supported PHP extensions, but did find this sample phpinfo() output: https://v83-php-info.pantheonsite.io/

Among the installed PECL extensions are igbinary, imagick, mongodb, msgpack, and oauth (which I note lists the version as "2.0.8dev").

Meanwhile, extensions which are bundled with PHP but *not* installed on Pantheon include ext/dba, ext/gd, ext/ffi, ext/pspell, ext/sysvmsg, ext/sysvsem, and ext/sysvshm

Clearly they have a policy for which extensions to install that is not driven by whether they ship in php-src or PECL.



Then let us redirect our discussion as to whether it would be beneficial to adopt wasmer-php into php-src repo, an objective list of reasons it would not, if not, and an objective list of things it could do to resolve those objections.


We can certainly do that. I'm not sure if there's a strict checklist, but from my understanding, here's a few of the things we'd need to consider:

Licensing - Could PHP legally distribute the extension?
+ Wasmer-PHP is under the MIT License, so should be fine.

Stability & Maturity - Is the extension ready for production use? Is it in a state where one feature release per year will be sufficient?
+ Wasmer-PHP describes itself as "complete and mature", so seems promising at a glance.

Portability - does the extension support the platforms PHP supports?
- The compatibility table in the readme shows only Linux and Darwin on amd64, with Windows support notably lacking. I'm not sure if this would be considered a show-stopper.

Dependencies - What is needed to build and run it? Does that present any licensing and portability concerns?
~ The extension itself seems to be self-contained C code (no C++, Rust, or additional build tools). I haven't looked into the runtimes that it would interface to.

Maintenance - is there somebody, and ideally several people, actively responding to bug reports and compatibility updates? [See https://github.com/php/php-src/blob/master/EXTENSIONS]
- This looks like a problem; the last release was over 3 years ago, and there doesn't seem to have been any activity on the public repo since.

I also can't see any mention of it on the main Wasmer project site at https://wasmer.io/products/runtime or the docs at https://docs.wasmer.io/ The Wayback Machine shows the previous version of their docs listed PHP as one of  8 "language integrations", but that didn't carry across when they rewrote it last summer: http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They may be intending to come back to it later, but at the moment it seems they are not dedicating any resources to it.


Regards,

-- 
Rowan Tommins
[IMSoP]
--------------L1O0Q0ZeFp7clrxbcC7bYTse--