> On Sep 20, 2024, at 3:56 AM, Arvids Godjuks <arvids.godj...@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: - https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions <https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions> - https://laravel.com/docs/11.x/deployment#server-requirements <https://laravel.com/docs/11.x/deployment#server-requirements> - https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions <https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions> 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 – typically run in sandboxed containers — 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étente? 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.ni...@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....@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 — 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. I absolutely love that Larry called the question if it were technically possible. Maybe Larry will read this and can answer the question — since he was heavily involved with Drupal — "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 <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 <https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions> > On Sep 20, 2024, at 8:51 PM, Hammed Ajao <hamieg...@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’s 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 — e.g. WASM — 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....@rwec.co.uk> > wrote: > On 20 September 2024 06:20:46 BST, Mike Schinkel <m...@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: >> >> • cURL >> • GD >> • PDO >> • OpenSSL >> • MBString >> • Zlib >> • Zip >> • XSL >> • EXIF >> • 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=wasm` 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-extensions <https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions> - https://laravel.com/docs/11.x/deployment#server-requirements <https://laravel.com/docs/11.x/deployment#server-requirements> - https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions <https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions> 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
