Compatibility with openswoole 22

[Alejandro Celaya]

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	ideally, no

Summary

I have tried a project where I use this library with openswoole, and using openswoole 22.0.0, there seems to be calls to now removed functions (So far I have identified Fatal error: Uncaught Error: Call to undefined function swoole_set_process_name() in mezzio/mezzio-swoole/src/Event/ProcessNameTrait.php:33).

I believe this is the first version that trully deviates from swoole and might require considering how hard would be to continue supporting both.

The changelog does not mention the removal of this particular function, so I wonder how many other undocumented changes there are.

[Alejandro Celaya]

Maybe using openswoole/ide-helper:22.0.0 helps identifying which functions/methods have been removed or changed.

Also, this version has built-in support for psr-7. Might simplify integrating it.

[mairo744]

I think it is more difficult than only removed swoole_set_process_name - https://openswoole.com/article/v22-0-0-released.

All classes changed at least namespace - example Swoole\Http\Server to OpenSwoole\Http\Server.

Will mezzio-swoole support also openswoole?

[Frank Brückner]

@mairo744

Will mezzio-swoole support also openswoole?

It is already building on this: https://docs.mezzio.dev/mezzio-swoole/v4/intro/#swoole

Should modifications to the latest versions be necessary, then any help is welcome!

[Marco Pivetta]

Worth checking this too, as a smoke test: laminas/laminas.dev#40

edit: that swoole from dev container is not actually used by automation or deployments.

[Alexandr Vronskiy]

@mairo744

All classes changed at least namespace - example Swoole\Http\Server to OpenSwoole\Http\Server.

Namespace \Swoole is still supported in v22.x (look release notes)

[Alexandr Vronskiy]

Maybe it can help someone right now. Can be solved error above with some hack, just call (before server start)

WorkerStartListener::$setProcessName = '\OpenSwoole\Util::setProcessName';
ServerStartListener::$setProcessName = '\OpenSwoole\Util::setProcessName';

bacause $setProcessName static & public property - it was worked solution. )

More right way (specially for this library) write own function swoole_set_process_name (wrapper on `OpenSwoole\Util::setProcessName`) and include it in composer autoload.
With IF conditional then can make support and swoole / openswoole / 4.x / 5.x / 22.x

[dcl20p]

This is how I quickly solved the problem without having to interfere with the library:

<?php
use OpenSwoole\Util;
// Override the swoole_set_process_name function
if (!function_exists('swoole_set_process_name')) {
  function swoole_set_process_name($name) {
      Util::setProcessName($name);
  }
}

Can check the version of swoole > 4.6.0 to override:
if (version_compare(swoole_version(), '4.6.0', '>=')) { // Override }

[Madalin Ignisca]

I would like to know if the focus will be 1st on OpenSwoole, and only keep compatibility with Swoole or even remove support for it.

Case: Newcomers to Mezzio, reading the official docs are guided for OpenSwoole.

I looked over the testing setup in the project, and noticed that it is testing against Swoole and not OpenSwoole.

Wouldn't it be OK to refactor the tests to use OpenSwoole? They do have an official PPA that works on top of Sury's PHP PPA currently used.

If the focus in code will be always 1st on Swoole, then the docs should be changed so less experienced people will not get in issues mezzio-swoole.

[Matthew Weier O'Phinney]

@madalinignisca We (the Laminas TSC) have been discussing splitting the repo so that this one targets only Swoole, and a new one targets specifically OpenSwoole. The reason is because:

• The two have diverged in API and features.
• The two are progressing at different speeds (OpenSwoole has not had new features, other than PHP 8.3 support, in over a year).

We do not currently have a timeline for this. It will require first a new minor (deprecating OpenSwoole usage here), and then a new major (removing support for OpenSwoole here).