search

pixelfederation / swoole-bundle

Symfony Swoole Bundle
MIT License
32 stars 12 forks source link

Swoole vs OpenSwoole #80

Open d-olim opened 2 years ago

d-olim commented 2 years ago

Hello, and thank you for taking over the maintenance of this bundle. I wasn't sure if reporting this as bug or feature request. It is really a point of discussion on how this bundle will evolve and which project it will track. I am aware that there have been security concern and discussion on the whole openswoole vs swoole in past, but I can't see open-swoole being maintained and curated as much as swoole project, and digging into detail of the issue it appeared to me that there weren't any real security concern in swoole project itself.

Though, this https://github.com/pixelfederation/swoole-bundle/compare/v0.11.0...v0.11.1 was effectively a breaking change.

There is no guarantee the 2 projects will stay aligned and in fact they are already diverging so I know this bundle will find it hard to follow both, but what are your thoughts or plans if any to support the original swoole ?

Describe the bug This fork doesn't support anymore swoole extension but only open swoole since version 0.11.1

Steps To Reproduce Try to run this bundle with swoole extension instead of open swoole would lead to error

Expected behavior I would expect this bundle to continue supporting Swoole

Rastusik commented 2 years ago

Hi @d-olim we currently don't have resources to support both of the extensions. For now we are choosing open swoole (it still is in development, new release should be coming soon). Feel free to help with supporting swoole if you have time for that.

pistej commented 1 year ago

any update on this? because I'm interested in workin xdebug with swoole :) https://github.com/swoole/docker-swoole/blob/master/examples/34-debug-with-xdebug/README.md

Rastusik commented 1 year ago

I'm planning to do this, but I don't have time right now. Some preliminary work has already been already started, but it's almost zero. I plan to support both extensions at least for the sake of xdebug usage, but since openswoole changed a lot, I need to setup the pipeline for all the combinations with swoole and openswoole and I need to implement an abstraction layer between the two APIs. And it's summer :)

pistej commented 1 year ago

for now I don't care about openswoole 22.0.* its mostly renaming :)

Rastusik commented 1 year ago

it's not mostly renaming because if you want to support both extensions after v 22, there has to be an abstraction layer, translating the calls for specific extension. but as the first step I probably can just enable support for 4.x versions of both extensions, or maybe also 5.x of Swoole, since the API didn't change (or didn't change much, not sure).

OpenSwoole 22 can be done later.

But now, I'm not sure about the timing of both of the steps.

pistej commented 1 year ago

Hi, @Rastusik I can help with adding support for 4.x version of both ext. and also support for 5.x of swoole, any idea how to start, or about abstraction layer ... or should I think about smth. ?!