Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125657
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------OsTqEx90mzS3pFbWZo5DqPqn"
Message-ID: <a6be7aea-621d-4cd0-a9ae-4177eda3275a@rwec.co.uk>
Date: Mon, 23 Sep 2024 21:09:15 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Zephir, and other tangents
To: internals@lists.php.net
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
 <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk>
 <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
 <CA+Jpajkx0OraH7GQyB5gECtPOo2JP=RzuSwqfv4AZGY+a+ryPw@mail.gmail.com>
 <AACF228F-53D3-480F-9127-77FBC4AE6A84@newclarity.net>
 <CAGnYymDhy1dov+4HcFWhAx1Ga9bXR=Urew9RbN5KEXcgHmk=Ew@mail.gmail.com>
 <f433fbe1-bee4-4a61-ba18-90053975b29e@app.fastmail.com>
 <BB0310CD-8134-4B3F-9C51-B59B5A24405F@automattic.com>
 <CA+Jpajnk9i=EhqXaKnYUTHhA_1TfzB1qiLfRh1whPoO8Y8ECqA@mail.gmail.com>
 <7EA884D2-0F37-4BF1-AC97-DB6953C944E6@automattic.com>
 <CAL0xaBHKUxwbzAYaPHevLSAEvWOQRPLsraxEg3oQtJ=wTxAkiw@mail.gmail.com>
 <042AF6B3-ACAD-498E-99FA-CD7EDE8778FC@newclarity.net>
 <CAGnYymAiTpKh+tZN7z5npVCy9Zshec6Odmzc5c4J5UAucT-5RQ@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAGnYymAiTpKh+tZN7z5npVCy9Zshec6Odmzc5c4J5UAucT-5RQ@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------OsTqEx90mzS3pFbWZo5DqPqn
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 23/09/2024 18:07, Adam Zielinski wrote:
> If PHP had WASM support,
> WordPress could ship curl.wasm as a fallback and focus on the product
> more than on the plumbing.


As has been pointed out a couple of times already, this particular use 
case really doesn't stand up to scrutiny.

- The chances of PHP making it a requirement that everybody who installs 
the PHP runtime *must* also install a WASM runtime are close to zero. 
It's actually much more plausible (though still unlikely) that we would 
make libcurl a hard requirement.
- Hosts who do not install ext/curl because they don't trust it are very 
unlikely to trust something as complex and versatile as a WASM runtime.
- Hosts who do not install ext/curl because they only install the base 
package provided by Ubuntu/RedHat/Alpine/etc won't install an ext/wasm, 
because it won't be included in that base package. I can't stress enough 
that those base packages are not "the default build of php-src", they 
are entirely controlled by the package managers at each 
distribution/repository.
- Hosts who already install a variety of PHP extensions will already 
install ext/curl, so are not relevant *for this particular example*.


The use case I *can* see is for *high-end* hosting services, who already 
install a range of extensions, including ext/curl, but don't allow users 
to upload binaries. (Mike gave the example of Pantheon.) They might 
allow users to upload and run more niche extensions, if it was proven 
that WASM provided a better sandbox than just running binary code inside 
an OS container.

I don't actually know what market share that kind of service has, with 
cheaper shared hosts on one side, and container-based hosting like 
DigitalOcean (where you can upload native binaries already) on the other.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------OsTqEx90mzS3pFbWZo5DqPqn
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 23/09/2024 18:07, Adam Zielinski
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGnYymAiTpKh+tZN7z5npVCy9Zshec6Odmzc5c4J5UAucT-5RQ@mail.gmail.com">
      <pre>If PHP had WASM support,
WordPress could ship curl.wasm as a fallback and focus on the product
more than on the plumbing.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>As has been pointed out a couple of times already, this
      particular use case really doesn't stand up to scrutiny.</p>
    <p>- The chances of PHP making it a requirement that everybody who
      installs the PHP runtime *must* also install a WASM runtime are
      close to zero. It's actually much more plausible (though still
      unlikely) that we would make libcurl a hard requirement.<br>
      - Hosts who do not install ext/curl because they don't trust it
      are very unlikely to trust something as complex and versatile as a
      WASM runtime.<br>
      - Hosts who do not install ext/curl because they only install the
      base package provided by Ubuntu/RedHat/Alpine/etc won't install an
      ext/wasm, because it won't be included in that base package. I
      can't stress enough that those base packages are not "the default
      build of php-src", they are entirely controlled by the package
      managers at each distribution/repository.<br>
      - Hosts who already install a variety of PHP extensions will
      already install ext/curl, so are not relevant *for this particular
      example*.</p>
    <p><br>
    </p>
    <p>The use case I *can* see is for *high-end* hosting services, who
      already install a range of extensions, including ext/curl, but
      don't allow users to upload binaries. (Mike gave the example of
      Pantheon.) They might allow users to upload and run more niche
      extensions, if it was proven that WASM provided a better sandbox
      than just running binary code inside an OS container. </p>
    <p>I don't actually know what market share that kind of service has,
      with cheaper shared hosts on one side, and container-based hosting
      like DigitalOcean (where you can upload native binaries already)
      on the other.<br>
    </p>
    <br>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------OsTqEx90mzS3pFbWZo5DqPqn--