Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125653 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 36EA21A00BD for ; Mon, 23 Sep 2024 06:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1727072200; bh=IM+ugDom7JNZjk2TdIr5dDAS4+S36+XaO7OJnk5iE+0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=IOWjm/xQaQvds2QioPkFJErgRpTBFDooWRh3n5JR6zAtgxMJkqFssJNWzN3LsfHno NmWFzLn1I0/fyCd9E39fAubETXgIMeCPCqAVqP0jf2QGoCP7P/sXKV7K7Rvpc2xOB3 dJtmNnnOcz4bELJBYbMrh/k6o1uvzufEWugpoNulkirQtickC4iE1POFixoe2DJ1dY x1i1PKylI28dRwtN4wJLEaMVA+vPekhykBvvJQujSieiFmOUNKfHYddlm2ymrHihyJ BfWbLVegEJIGyXvnXuERBs/ykjZ1tjtInzl5BvD2NpjnJz3nw/d0faR1b/+M3XP1Mg EvbXXcmzfQx3g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8CFEC180071 for ; Mon, 23 Sep 2024 06:16:38 +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.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 06:16:38 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-6d9f65f9e3eso32211017b3.3 for ; Sun, 22 Sep 2024 23:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1727072069; x=1727676869; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=RRP22feEX+LJQYqubwfUjnv59Bf9DiWxS2/1z30PdIA=; b=PVmuRg8FyNOlD1fe7JUA/k/kFr7qHMR/plxMsSejWP+eSsiAjNebOH0gC2HN75pmf+ /Y7ikNX4XFDqTtuapNL+JMepn+S8YnCQJrzm31f6gO2fKBhK73NCKfm9EShboYRG/ars gGi6ynZpJmG/hXV/z49O+WJYroiAEAfUGHZ0pjEdTSvZoLpZ95zzS6WIBm//NieEGFqZ IADObnt0MHS/JrLyOcxQPNe79OC9Vl/Le65BPQPcmjZno+UAn7X8uVjvpvGUID59TSxR 33r+u6zBMQOxC8qxTwt1bsmjc9/w5ZGGLgf0paN/RCjthuPXQAFWR38FqR9wn/s9/4XH OeMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727072069; x=1727676869; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RRP22feEX+LJQYqubwfUjnv59Bf9DiWxS2/1z30PdIA=; b=SgQO3ifIT2cd7BSFJL4cXUZztj2MNe3WWuK//2f5yGzpL+cAn+YaBJqUeZoO/XDnxC xiorezcFhsQIKIjEOog0N5RId+aygyR4o7dFdzIGZ/TuRdqPvJsMj8JJeq/vboSS6REO 6rqSWHnpmcrtA+TaXwyOounf7FXAiQrRx0SouOW6ajAPMPNPV3HhictFmMZVbfs0j02k NiPfJOtNmZCMQyEbZG/Id3U3HPBH1DXNZLhS4OFUrXLd7GCOo3FsI58dqfXFzmkewSz/ ceP9rLEYUcTlFK+fJELKIVvyEj9kREeLhpua+lXKPpvl9NoLkiSev8C/+rD7CHEZeh/H WAaQ== X-Forwarded-Encrypted: i=1; AJvYcCX2BliAy3dSezyg4zVhlgMsxVErvPgJIITMVyfG/m8mXt0fX0mCRn71/Xgxf9dtIE29eSbnGHnHpfY=@lists.php.net X-Gm-Message-State: AOJu0YyMZr632SZjDeZb4/G8S1v1yUBUy8glyrjjjWPxMfeDN+sBgNwl Ia6yXDj8G2vrINMZQXEDjZOGpctIfVYs2P/2F44WtjciAh5U2WTmgguavJinCW4= X-Google-Smtp-Source: AGHT+IFibE6izqKK2lvCzXXzwMi2+ewNjQyhLLVaPNruNc9XpyJHe6K7oTizGJ4SigtHBOY6GyX06w== X-Received: by 2002:a05:690c:6183:b0:6d7:4dea:5f16 with SMTP id 00721157ae682-6dfeed5b3eemr84148167b3.26.1727072068919; Sun, 22 Sep 2024 23:14:28 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6dbe2df06fesm33708307b3.9.2024.09.22.23.14.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2024 23:14:27 -0700 (PDT) Message-ID: <042AF6B3-ACAD-498E-99FA-CD7EDE8778FC@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_366378A4-C7A9-44B5-9FA3-C3AA962BF99C" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: [PHP-DEV] Zephir, and other tangents Date: Mon, 23 Sep 2024 02:14:26 -0400 In-Reply-To: Cc: Dennis Snell , Rob Landers , Adam Zielinski , PHP internals To: Arvids Godjuks , Niels Dossche , Larry Garfield , "Rowan Tommins [IMSoP]" , Hammed Ajao References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> <7EA884D2-0F37-4BF1-AC97-DB6953C944E6@automattic.com> X-Mailer: Apple Mail (2.3696.120.41.1.10) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_366378A4-C7A9-44B5-9FA3-C3AA962BF99C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 20, 2024, at 3:56 AM, Arvids Godjuks = wrote: > I want to chip in here, since reading the thread lead me into a state = of cognitive dissonance. > I've been in PHP world for a long time, about 3 years shy of how old = Wordpress is. When I'm reading "shared hosting" and "WASM" and knowing = how managed hosting works, I have to ask: What type of la-la land is = this conversation is taking place in? See these lists above showing the required and recommended extensions = for WordPress, Laravel and Drupal where all(?) other CMS/frameworks have = an equivalent list: - = https://make.wordpress.org/hosting/handbook/server-environment/#php-extens= ions = - https://laravel.com/docs/11.x/deployment#server-requirements = =20 - = https://www.drupal.org/docs/getting-started/system-requirements/php-requir= ements#extensions = =20 Managed hosts that want to sell to users of a CMS or frameworks operate = in the "la-la land" you speak of. > what managed hoster in their right mind and sanity will allow WASM to = be enabled to bypass ____A L L _____ PHP security features and allow PHP = code do anything it wants? That is a false assertion. WASM cannot bypass all PHP security; it is = by-nature sandboxed. Yes, there are ways that a good C++ developer could get around that, but = as part of this discussion we have been discussing ways to avoid = allowing that, such as potentially enabling WASM for PHP to only allow = using AssemblyScript, at least initially. > On a shared hosting... I seriously want to know answer to this = question, because I firmly believe there was zero risk and security = assessment not only done, but it hasn't been even a twinkle in the eye. >=20 > On VPS/Decicated you can run whatever you want, so you don't have the = limitations. Shared hosting vs. VPS/Dedicated is a false dichotomy.=20 There is also managed hosting =E2=80=93 typically run in sandboxed = containers =E2=80=94 that specialize in running specific CMS and/or = frameworks. > On other note - people have pointed out how big body of work it is. If = you want to sponsor WASM development for PHP, I suggest Automatic open = their wallet and put in 2-3 million $ a year for the next 5-10 years to = PHPFoundation and find devs who are capable and willing to do this job. = Honestly, I think you might find people to want to do that rather than = lack of money being the cause of it. Well, that is an option, and I would be glad to see it.=20 However, my guess is that Automattic (spelled correctly) is not likely = to do that given how dismissive PHP Internals and by extension the PHP = Foundation has been regarding the needs of WordPress users for as long = as you Arvids have been doing PHP. =20 But who knows, maybe there could be a d=C3=A9tente? Who on this list = would be more open than in the past to treat concerns of WordPress users = as legitimate rather than dismiss them because (I am paraphrasing) "how = bad their code is?" > On Sep 20, 2024, at 3:39 PM, Niels Dossche = wrote: > Perhaps I'm missing something in this discussion, as this discussion = has all sorts of tangents and is quite lengthy. Also easy to forget = what's been said and not. > Anyway, there is already a wasm extension for PHP: = https://github.com/veewee/ext-wasm The something you might be missing is the discussion is about = potentially having WASM as a bundled extension in PHP core rather than = there just having one be available, and the reason is so that it can = become a viable option for CMS & Framework vendors to include on their = list of required or at least recommended extensions. > On Sep 20, 2024, at 7:27 PM, Rowan Tommins [IMSoP] = wrote: > It's absolutely possible to build a PHP extension that interfaces to a = WASM runtime, and links have been shared to at least two projects doing = just that. Adding that to the php-src repo doesn't change what that = extension can do, it just marks it as "approved" in some slightly = ill-defined way, and restricts it to having new releases only once per = year. >=20 > 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) 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 =E2=80=94= e.g. none with a large userbase =E2=80=94 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. I absolutely love that Larry called the question if it were technically = possible. Maybe Larry will read this and can answer the question =E2=80=94= since he was heavily involved with Drupal =E2=80=94 "Would Drupal be = willing to require or at least recommend a 3rd party WASM extension vs. = a bundled one here? = https://www.drupal.org/docs/getting-started/system-requirements/php-requir= ements#extensions = " > At which point, some managed hosting servers might be more willing to = install it. Not the ones who don't even install ext/curl, those are = never going to benefit from this.=20 There are very few (if any) that won't install curl as you cannot run = WordPress w/o curl. Your knowledge of what hosting providers will and = will not install seems to be rather dated. > But maybe the ones who install a reasonable list of features, but are = a bit wary of installing PECL extensions they don't know much about, can = be persuaded to trust their users with a WASM sandbox. Or the ones who want to target the users of the CMS or Framework that = recommend or require the extension. If the extension were bundled then I expect it could become a = recommended extension for hosts to enable and WordPress could start = shipping WASM extensions for the use-cases Dennis Snell mentioned that = can optionally run if the WASM extension is enabled vs. if not it would = just run the old slower PHP code. BTW, Dennis, could you see WordPress recommending a WASM extension if = PHP bundled one here? = https://make.wordpress.org/hosting/handbook/server-environment/#php-extens= ions = > On Sep 20, 2024, at 8:51 PM, Hammed Ajao wrote: > Ah so you want to make huge changes to the engine for even less users? Why make such a leading yet false assertion? The fact it can be implemented in an PHP extension discretions your = assert that it would require "huge changes to the engine." In fact, it = would not require *any* changes to the engine. > If you insist, I'll await your MVP. Here it is: https://github.com/wasmerio/wasmer-php/releases/tag/1.1.0 > So maybe those companies should implement it themselves or pay to have = it implemented. Or maybe those companies just give up on using PHP rather than = constantly deal with intransigence among community members when = improvements are even mentioned? Most of my work has been in Go lately, = motivated in large part because of PHP's governance model that centers = around this list and the hostile and non-constructive reactions that are = far too common on this list. > How would we handle the JS-like stdlib of assembly script? Another = abstraction layer? That seems easier to you than a DSL created = specifically for this?=20 You mischaracterize, but yes, an existing working WASM is easier IMO = than a DSL that is just "concepts of a plan." (Those quotes were not yours, I am just making a pun on something that = was said recently by someone well-known in the USA.) > With PHP like syntax?=20 Why is "PHP like syntax" a blocking requirement? C does not have a = PHP-like syntax, or at least one that is not more similar to = AssemblyScript than PHP. Why then is C acceptable for extensions but = AssemblyScript is not? And even so, there is no reason a PHP-like syntax is required. PHP = developers work with JS or TS every day, and AssemblyScript is just a = variant of TypeScript. > Using the parser already in the engine? With a PHP-like stdlib? > =20 >=20 > > > In essence, WebAssembly is great for certain scenarios, but PHP = has existing mechanisms that make the addition of a Wasm runtime = potentially redundant for most use cases.=20 >=20 > Then for those cases where it is redundant, don't use it. >=20 > That's most use cases. It doesn't make any sense to burden all users = and contributors just so some companies can maybe decide to enable wasm = to make more money. First, it would not burden all users nor all contributors; that is an = invalid claim I have discredited above. Second, that sounded like a Freudian slip where you said the quiet part = out loud. Is this about you somehow having a hot button about "some = people wanting to make money" rather than accepting people just want to = be able to write better and faster websites in PHP? If "some people = wanting to make money" were the discrediting bar then (almost?) every = feature request could be denied on that basis.=20 > Honestly, a DSL would be the perfect solution here. Anyone familiar = with writing PHP extensions knows about `gen_stub.php`, which scans PHP = stubs and generates the corresponding binding C code.=20 When and where does the C code get compiled?=20 And isn't that what Zephir actually is? > I've often thought this process could be extended to handle more = complex scenarios like promoted properties, simple expressions (e.g., = assignments, property access, comparisons), and anything that can be = easily translated into C code. >=20 > V8 has a similar tool called Torque, and I've always wondered what = something like that would look like for PHP. It would result in a = strict, statically typed subset of PHP that satisfies all the = requirements, except for the last one (which it would only partially = fulfill). >=20 > Since the generated code would interface directly with the Zend API, = we can consider the DSL code as safe as the PHP implementation itself. = While there wouldn't be CPU throttling, hosts shouldn't have major = objections since it would essentially be as safe as PHP. >=20 > Most importantly, this approach would benefit everyone. It would have = no third-party dependencies and would only need to evolve alongside = PHP/Zend as they grow. >=20 > That=E2=80=99s how I would approach it. I await your proposal. Sincerely.=20 And I don't mean to the level of an RFC, but a document that details how = it would work, and one that could be discussed and commented on as you = can on a Github repo. Note I am not advocating fro a *specific* approach =E2=80=94 e.g. WASM = =E2=80=94 I am advocated to achieved the stated goal, e.g. an extension = mechanism that can run at near native speed for low-level string parsing = and maths that realistically will be able to be run on managed hosts = which IMO means they have to be adopted by major CMS and/or Frameworks = as requirements if not at least recommendations.=20 If your ideas can achieve those goals, I would fully be behind them. (I = am however skeptical that what you proposal can achieve all those goals; = prove me wrong.) > On Sep 20, 2024, at 4:18 AM, Rowan Tommins [IMSoP] = wrote: > On 20 September 2024 06:20:46 BST, Mike Schinkel = wrote: >> Moot point as it cannot be run on a managed hosted server. >=20 > Why not? Only because the people managing that server haven't been = persuaded to include it as an option. And that is mostly because it's = currently experimental, and there isn't wide demand for it. You can hypothetical all day long, but the reality is that if something = is not shipped with PHP, someone wanting to write PHP code that a = library, CMS or frameworks depends on would have to play a = failure-guaranteed game of whack-a-mole to get a lot of managed hosting = providers to support it.=20 And the larger CMS and frameworks are rightly not going to support = something that does not get bundled into php-src. >>> Just to reiterate, if by "built-in to PHP core", you mean "every = copy of PHP includes a functional WASM runtime", that's not going to = happen. It would mean bundling (or requiring every user to install) a = huge third-party dependency, with all of its dependencies and platform = requirements, even if they weren't interested in using it. >>=20 >> So why do you claim that bundling a third-party dependency is a = "never going to happen" scenario? =20 >>=20 >> By that logic PHP would have none of these functionalities: >>=20 >> =E2=80=A2 cURL >> =E2=80=A2 GD >> =E2=80=A2 PDO >> =E2=80=A2 OpenSSL >> =E2=80=A2 MBString >> =E2=80=A2 Zlib >> =E2=80=A2 Zip >> =E2=80=A2 XSL >> =E2=80=A2 EXIF >> =E2=80=A2 BCMath >=20 > None of those are "built into PHP core" in the sense of "every copy of = PHP includes them". Nor do any of them bundle their third-party = dependencies.They are all optional extensions, which the user has to = provide the dependencies for if they want to install and enable them. Fine, we can treat WASM the same as all those other extensions and = bundling it with PHP meaning `;extension=3Dwasm` line in production.ini, = the internal code needed to link in the library, and compiler switches = to compile it in. If PHP were to ship in this way then CMS and Frameworks could choose to = add WASM to their list of required or recommended extensions, as it = sounds like from Dennis Snell's really excellent messages that WordPress = would likely want to do that: - = https://make.wordpress.org/hosting/handbook/server-environment/#php-extens= ions = - https://laravel.com/docs/11.x/deployment#server-requirements = =20 - = https://www.drupal.org/docs/getting-started/system-requirements/php-requir= ements#extensions = =20 Once CMS & Frameworks are empowered to use WASM as part of their core = offering then they could start recommending WASM and managed web hosts = that want to cater to their users would start offering WASM enabled on = their platforms. BTW, very few CMS or Frameworks make any extensions not referenced in = production.ini as requirements, and for very good reason because doing = so would be too risky.=20 > They are what is sometimes referred to as "bundled extensions", which = just means they have source code in the php-src repository, and get new = releases at the same time as PHP. Being in that list doesn't mean = managed hosts have to provide them (who would force them?) and not being = in that list doesn't mean managed hosts can't provide them (it's as easy = to install "php-mongodb" on Ubuntu as "php-mysqli", even though one is = "bundled" and the other hosted on PECL). >=20 > Being "bundled" may be interpreted as something of a "stamp of = approval", indicating that an extension is mainstream and stable. That's = something that has to be earned - many extensions started out in their = own projects, with releases listed on PECL or elsewhere, and were = proposed for adoption into the php-src repo once they became stable. >=20 > Which is why I say your energies for now are best spent on a project = like extism, or wasmer-php - build that stable extension, and then we = can discuss whether it would be beneficial to adopt it into the php-src = repo. 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.=20 That would be much more productive than debating hypotheticals. -Mike= --Apple-Mail=_366378A4-C7A9-44B5-9FA3-C3AA962BF99C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Sep 20, 2024, at 3:56 AM, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
I want to chip in = here, since reading the thread lead me into a state of cognitive = dissonance.
I've been in PHP world for a = long time, about 3 years shy of how old Wordpress is. When I'm = reading "shared hosting" and "WASM" and knowing how managed hosting = works, I have to ask: What type of la-la land is this conversation is = taking place in?

See these lists above showing the required and = recommended extensions for WordPress, Laravel and Drupal where all(?) = other CMS/frameworks have an equivalent list:

Managed hosts that want to sell to users of = a CMS or frameworks operate in the "la-la land" you speak = of.


what managed hoster in their right mind and sanity will allow = WASM to be enabled to bypass ____A L L _____ PHP security features = and allow PHP code do anything it wants? =

That is a = false assertion. WASM cannot bypass all PHP security; it is by-nature = sandboxed.

Yes, there are ways that = a good C++ developer could get around that, but as part of this = discussion we have been discussing ways to avoid allowing that, such as = potentially enabling WASM for PHP to only allow using AssemblyScript, at = least initially.

On = a shared hosting... I seriously want to know answer to this question, = because I firmly believe there was zero risk and security assessment not = only done, but it hasn't been even a twinkle in the eye.

On VPS/Decicated you can = run whatever you want, so you don't have the = limitations.

Shared hosting vs. VPS/Dedicated is a false = dichotomy. 

There is also = managed hosting =E2=80=93 typically run in sandboxed containers =E2=80=94 = that specialize in running specific CMS and/or frameworks.

On other note - people have = pointed out how big body of work it is. If you want to sponsor WASM = development for PHP, I suggest Automatic open their wallet and put in = 2-3 million $ a year for the next 5-10 years to PHPFoundation and find = devs who are capable and willing to do this job. Honestly, I think you = might find people to want to do that rather than lack of money being the = cause of it.

Well,= that is an option, and I would be glad to see it. 

However, my guess is that Automattic (spelled = correctly) is not likely to do that given how dismissive PHP Internals = and by extension the PHP Foundation has been regarding the needs of = WordPress users for as long as you Arvids have been doing PHP. =  

But who knows, maybe there = could be a d=C3=A9tente?  Who on this list would be more open than = in the past to treat concerns of WordPress users as legitimate rather = than dismiss them because (I am paraphrasing) "how bad their code = is?"

On Sep 20, 2024, at 3:39 PM, Niels Dossche = <dossche.niels@gmail.com> wrote:
Perhaps I'm missing something in this discussion, as this = discussion has all sorts of tangents and is quite lengthy. Also easy to = forget what's been said and not.
Anyway, there is already = a wasm extension for PHP: https://github.com/veewee/ext-wasm

The = something you might be missing is the discussion is about potentially = having WASM as a bundled extension in PHP core rather than there just = having one be available, and the reason is so that it can become a = viable option for CMS & Framework vendors to include on their list = of required or at least recommended extensions.

On = Sep 20, 2024, at 7:27 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
It's = absolutely possible to build a PHP extension that interfaces to a WASM = runtime, and links have been shared to at least two projects doing just = that. Adding that to the php-src repo doesn't change what that extension = can do, it just marks it as "approved" in some slightly ill-defined way, = and restricts it to having new releases only once per year.

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)

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 =E2=80=94 e.g. none = with a large userbase =E2=80=94 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.

I absolutely love that Larry called the question = if it were technically possible.  Maybe Larry will read this and = can answer the question =E2=80=94 since he was heavily involved with = Drupal =E2=80=94 "Would Drupal be willing to require or at least = recommend a 3rd party WASM extension vs. a bundled one here? https://www.drupal.org/docs/getting-started/system-requirements= /php-requirements#extensions"

At which point, = some managed hosting servers might be more willing to install it. Not = the ones who don't even install ext/curl, those are never going to = benefit from this. 

There are = very few (if any) that won't install curl as you cannot run WordPress = w/o curl.  Your knowledge of what hosting providers will and will = not install seems to be rather dated.

But maybe the ones who install a reasonable = list of features, but are a bit wary of installing PECL extensions they = don't know much about, can be persuaded to trust their users with a WASM = sandbox.

Or the = ones who want to target the users of the CMS or Framework that recommend = or require the extension.

If the = extension were bundled then I expect it could become a recommended = extension for hosts to enable and WordPress could start shipping WASM = extensions for the use-cases Dennis Snell mentioned that can optionally = run if the WASM extension is enabled vs. if not it would just run the = old slower PHP code.

BTW, Dennis, = could you see WordPress recommending a WASM extension if PHP bundled one = here? https://make.wordpress.org/hosting/handbook/server-environment/= #php-extensions

On Sep 20, 2024, at 8:51 PM, Hammed Ajao = <hamiegold@gmail.com> wrote:
Ah so you want to make huge changes to the engine = for even less users?

Why make such a leading yet false = assertion?

The fact it can be = implemented in an PHP extension discretions your assert that it would = require "huge changes to the engine."  In fact, it would not = require *any* changes to the engine.

If you insist, I'll await your = MVP.

Here it is:  https://github.com/wasmerio/wasmer-php/releases/tag/1.1.0

So = maybe those companies should implement it themselves or pay to have it = implemented.

Or maybe those companies just give up on using PHP = rather than constantly deal with intransigence among community members = when improvements are even mentioned? Most of my work has been in Go = lately, motivated in large part because of PHP's governance model that = centers around this list and the hostile and non-constructive reactions = that are far too common on this list.

How would we handle the JS-like = stdlib of assembly script? Another abstraction layer? That seems easier = to you than a DSL created specifically for = this? 

You mischaracterize, but yes, an existing working = WASM is easier IMO than a DSL that is just "concepts of a = plan."

(Those quotes were not yours, = I am just making a pun on something that was said recently by someone = well-known in the USA.)

With PHP like = syntax? 

Why is "PHP like syntax" a blocking requirement? =  C does not have a PHP-like syntax, or at least one that is not = more similar to AssemblyScript than PHP.  Why then is C acceptable = for extensions but AssemblyScript is not?

And even so, there is no reason a PHP-like syntax = is required. PHP developers work with JS or TS every day, and = AssemblyScript is just a variant of TypeScript.

Using the parser = already in the engine? With a PHP-like stdlib?
 

> > In essence, WebAssembly is great for certain = scenarios, but PHP has existing mechanisms that make the addition of a = Wasm runtime potentially redundant for most use cases. 

Then for those cases where it is redundant, = don't use it.

That's most use cases. It doesn't make = any sense to burden all users and contributors just so some companies = can maybe decide to enable wasm to make more = money.

First,= it would not burden all users nor all contributors; that is an invalid = claim I have discredited above.

Second, that sounded like a Freudian slip where = you said the quiet part out loud. Is this about you somehow having a hot = button about "some people wanting to make money" rather than accepting = people just want to be able to write better and faster websites in PHP? = If "some people wanting to make money" were the discrediting bar = then (almost?) every feature request could be denied on that = basis. 

Honestly, a DSL would be the perfect solution here. Anyone = familiar with writing PHP extensions knows about `gen_stub.php`, which = scans PHP stubs and generates the corresponding binding C = code. 

When and where does the C code get = compiled? 

And isn't that what = Zephir actually is?

I've often thought this process could be extended to handle = more complex scenarios like promoted properties, simple expressions = (e.g., assignments, property access, comparisons), and anything that can = be easily translated into C code.

V8 has a = similar tool called Torque, and I've always wondered what something like = that would look like for PHP. It would result in a strict, statically = typed subset of PHP that satisfies all the requirements, except for the = last one (which it would only partially fulfill).

Since the generated code would interface directly with the = Zend API, we can consider the DSL code as safe as the PHP implementation = itself. While there wouldn't be CPU throttling, hosts shouldn't have = major objections since it would essentially be as safe as PHP.

Most importantly, this approach would benefit = everyone. It would have no third-party dependencies and would only need = to evolve alongside PHP/Zend as they grow.

That=E2=80=99s how I would approach it.

I = await your proposal.  Sincerely. 

And I don't mean to the level of an RFC, but a = document that details how it would work, and one that could be discussed = and commented on as you can on a Github repo.

Note I am not advocating fro a *specific* approach = =E2=80=94 e.g. WASM =E2=80=94 I am advocated to achieved the stated = goal, e.g. an extension mechanism that can run at near native speed for = low-level string parsing and maths that realistically will be able to be = run on managed hosts which IMO means they have to be adopted by major = CMS and/or Frameworks as requirements if not at least = recommendations. 

If your ideas = can achieve those goals, I would fully be behind them.  (I am = however skeptical that what you proposal can achieve all those goals; = prove me wrong.)

On Sep 20, 2024, at 4:18 AM, Rowan Tommins = [IMSoP] <imsop.php@rwec.co.uk> wrote:
On = 20 September 2024 06:20:46 BST, Mike Schinkel <mike@newclarity.net>= wrote:
Moot point as = it cannot be run on a managed hosted server.

Why not? Only because the people = managing that server haven't been persuaded to include it as an option. = And that is mostly because it's currently experimental, and there isn't = wide demand for it.

You can hypothetical all day long, but the reality is = that if something is not shipped with PHP, someone wanting to write PHP = code that a library, CMS or frameworks depends on would have to play a = failure-guaranteed game of whack-a-mole to get a lot of managed hosting = providers to support it. 

And = the larger CMS and frameworks are rightly not going to support something = that does not get bundled into php-src.

Just to = reiterate, if by "built-in to PHP core", you mean "every copy of PHP = includes a functional WASM runtime", that's not going to happen. It = would mean bundling (or requiring every user to install) a huge = third-party dependency, with all of its dependencies and platform = requirements, even if they weren't interested in using it.

So why do you claim that bundling = a third-party dependency is a "never going to happen" scenario? =  

By that logic PHP would have none of = these functionalities:

=E2=80=A2 cURL
=E2=80=A2 GD
=E2=80=A2 PDO
=E2=80=A2= OpenSSL
=E2=80=A2 MBString
=E2=80=A2 = Zlib
=E2=80=A2 Zip
=E2=80=A2 XSL
=E2=80=A2 EXIF
=E2=80=A2 BCMath

None of those are "built into PHP = core" in the sense of "every copy of PHP includes them". Nor do any of = them bundle their third-party dependencies.They are all optional = extensions, which the user has to provide the dependencies for if they = want to install and enable them.

Fine, we can treat WASM the same as all those = other extensions and bundling it with PHP meaning `;extension=3Dwasm` = line in production.ini, the internal code needed to link in the library, = and compiler switches to compile it in.

If PHP were to ship in this way then CMS and = Frameworks could choose to add WASM to their list of required or = recommended extensions, as it sounds like from Dennis Snell's really = excellent messages that WordPress would likely want to do = that:


Once CMS & Frameworks are empowered to use = WASM as part of their core offering then they could start recommending = WASM and managed web hosts that want to cater to their users would start = offering WASM enabled on their platforms.

BTW, very few CMS or Frameworks make any = extensions not referenced in production.ini as requirements, and for = very good reason because doing so would be too = risky. 

They are what is sometimes referred to as "bundled = extensions", which just means they have source code in the php-src = repository, and get new releases at the same time as PHP. Being in that = list doesn't mean managed hosts have to provide them (who would force = them?) and not being in that list doesn't mean managed hosts can't = provide them (it's as easy to install "php-mongodb" on Ubuntu as = "php-mysqli", even though one is "bundled" and the other hosted on = PECL).

Being "bundled" may be interpreted = as something of a "stamp of approval", indicating that an extension is = mainstream and stable. That's something that has to be earned - many = extensions started out in their own projects, with releases listed on = PECL or elsewhere, and were proposed for adoption into the php-src repo = once they became stable.

Which is why I say = your energies for now are best spent on a project like extism, or = wasmer-php - build that stable extension, and then we can discuss = whether it would be beneficial to adopt it into the php-src repo.

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. 

That would be much = more productive than debating hypotheticals.

-Mike
= --Apple-Mail=_366378A4-C7A9-44B5-9FA3-C3AA962BF99C--