decouple swoole to core and middleware parts

[jk2K]

attempts to split swoole to core and middleware parts, let the core team focus on core functionality development

middleware, such as http-server, redis, mysql, Hbase, ZooKeeper, ElasticSearch, maybe we can use PHP to implement, based on swoole ability, distributed by composer, If we use PHP to develop, the middleware package can get more contributions from the community

core feature, such as Event-Driven, Coroutine, we continue to develop with C/C++, install by PHP extension

This re-organization is also a good practice for maintenance, as these packages will be released separated, thus allowing more frequent updates

I propose to create multi repository, for example

• swoole/core: core feature, develop with C/C++, install by PHP extension
• swoole/swoole-http-server: use PHP, install by composer
• swoole/swoole-mysql: use PHP, install by composer
• swoole/swoole-redis: use PHP, install by composer
• to be continued

[seeme-o]

One think to keep in mind is that some of swoole's features are not possible in vanilla PHP or it's mainline extensions. For example PHP's MySQL extension (or any others in fact) lack the concept of coroutines, requiring swoole to maintain it's own. Wouldn't this make separation inconsistent? I see some features being possible in raw PHP such as swoole-http-server and swoole-redis, but others won't be possible at all without requiring some extent of the existing swoole C modules to be developed along side the new raw PHP versions in order to fill feature gaps.

[jk2K]

PHP RFC: FFI - Foreign Function Interface has been accepted, may be we can call the inevitable swoole C modules via FFI, to reduce some obstacles

[seeme-o]

Something like FFI can be awesome for PHP's future, but the PHP Group is slow at making these sorts of changes because of how complex they can be. The push that they have made with their incorporation of an AST is a big start, but even this is muddy water in areas. In the end the entire extension community will need to add hooks for these features. For example, how will FFI help make the standard MySQLi extension capable of understanding coros if FFI is used to make a native coroutine feature set like Swoole's when it doesn't even understand PHP coroutine's? In other words, FFI will make PHP capable of making native code, but what will it take for existing native extensions to work with these native instructions created by FFI? It will likely prove great for making algorithms for sorting things or even complex algorithms for codecs and ciphering, but even working with basic system libraries such as sockets will prove challenging, especially if your plan is to change how even basic libraries work.

[seeme-o]

I hope you don't tire of my 2 cents as I'm not an official voice of Swoole, but I really think Swoole should continue on the path they are going. In the near future it's possible to see other languages/platforms embracing Swoole such as Java and Node.js which can prove to be very significant. Imagine Node.js creating a Swoole table and PHP being able to access it (or vice versa) without a cost in performance. Or a Java package that can access Swoole Channel objects created within PHP. This is possible with the route that Swoole is on. It can be done right now if someone endeavored to do it. Separating major elements of Swoole and making them PHP dependent would require others to do the same work in other languages as well - Node.js would be able to link to the Swoole core, but middle-land features would need to be coded in Node.js Javascript, same for Java, Ruby, etc.

[jobs-git]

That's too silly, unless you want a slow php server, else http-server, mysql, and redis should remain in c/c++ coroutine implementations, others can become 3rd party.

[embluk]

I disagree with this structure, keeping everything the way it is is much simpler and easy to manage when running Swoole. Some parts cannot be done in PHP and if they could, it would be much slower. I like the way Swoole works currently.

I think, features like middleware, routes and database ORMs etc. need to be left to frameworks created for Swoole; just as I am doing with a dedicated web HTTP framework for Swoole https://github.com/Superbition/Polyel

Having everything available in the Swoole core makes development easier, I think its better to keep Redis, MySQL etc. all in the core.

Swoole should focus on what they started which is being a networking framework for PHP.