swoole / rfc

Swoole 提案
116 stars 3 forks source link

RFC-1009 内置 PHP 语言实现的标准库 swoole-src/lib #18

Open matyhtf opened 6 years ago

matyhtf commented 6 years ago

现状

目前swoole扩展底层仅提供驱动层能力,服务器端编程很多常用的功能并未提供,如连接池、rpc等,需要php代码实现。很多swoole框架都实现了对应的代码,产生了一定的重复工作。

官方提供标准库,可以让大家协作共同制定一套标准的library,供swoole社区用户使用。减少重复性工作,提升代码复用性。

参考对象node.jsnode主干中维护了一个lib目录,提供使用js语言实现的标准库。

https://github.com/nodejs/node/tree/master/lib

改进

最终实现中,用户对lib提供的类或函数是无感知的,无法区分是扩展定义还是lib定义。保持足够的清理,仅依赖swoole不依赖其他任何php类库或composer包。

选项

提供php.ini配置swoole.use_library = On/Off 开启或关闭标准库

投票

comoyi commented 6 years ago

有个想法,是否能够创建一个新的主仓库(命名空间)例如 swoole-lib,主要负责归纳公共包,像archlinux一样分core, extra, community, 根据投票决定是否进入core(swoole-lib), 框架根据需求引入相应的包。

amuluowin commented 6 years ago

能否创建一个官方社区,交流移到社区论坛,可以分多个板块(lib块,问题整理,中间件开发,框架,swoole) 1.lib块可以提议组件通过后立案,并组织开发,同时可以交流。 2.问题整理块,提问与回答,现在用q群的方式就比较弱了,整天都是一些没营养的讨论,同一个问题被问了很多遍。论坛的话回答一次就好,新手可以搜索。 3.框架块,一些优秀的框架推荐和教程,同时可以跟进框架的开发等。还有现在框架的组件虽然框架内不耦合,但是与框架耦合,这样复用性就很低了。 4.中间件块,现在很多中间件都是其他语言的,PHP很少中间件,但是有了swoole,中间件开发就很有必要了。项目大了之后中间件的应用就非常普及了,找个mq发现很多都是Java,很容易项目就转Java了。 5.swoole板块,可以了解swoole的新动作和新功能等。 社区建立起来后,很多PHP层的都会有人做,swoole组可以专注底层。最后祝fiber早日完成,这样现在流行框架的改造就能用上,普及率大幅提高,框架官方原生支持swoole也不见得是难事。

robberphex commented 6 years ago

同意这一点:

创建一个新的主仓库(命名空间)例如 swoole-lib,主要负责归纳公共包

lib放在swoole-src不符合用户场景。

kcloze commented 6 years ago

不是很理解为啥要一起打包进扩展?这样更新起来不是很麻烦? 赞同独立仓库,跟c代码分开

huangzhhui commented 6 years ago

我觉得是独立仓库会更好,这样能满足 Swoole 加载规则也能满足 Composer 的加载规则,更容易往 packagist 上发独立包,便于包的复用

fmfsaisai commented 6 years ago

https://github.com/fiberphp/fiber-ext https://wiki.php.net/rfc/fiber

Fiber 就要成为官方默认的协程模块了?

yyun543 commented 5 years ago

支持独立仓库, 同时支持Swoole和Composer的加载规则。希望能够把常用的针对Swoole优化过的Grpc、ETCD、Consul、Amqp、ES Client、DB、Cache等包都按照规范统一维护起来,大家就可以使用同一套标准的library了。

farwish commented 5 years ago

我觉的可行,因为是依赖swoole实现的东西,并不包含其它composer第三方库;但是伴随 swoole-src/lib 升级要更新扩展这个事就相对麻烦了,如果lib更新频繁 升级扩展将成为常态。

Moln commented 5 years ago

还是建议运用 Composer, 像 mongodb 一样, 提供PHP扩展外, 另 composer 提供 mongodb/mongodb

  1. IDE 代码自动提示, 还要另操作包引入.
  2. 如何解决 lib 下的语义化版本问题, 更新都通过 pecl ? 会又要重新编译 ? 那比 composer 更新还慢.
  3. 代码提示方面, 有些开发windows 环境开发, 是没有 pecl 的, 加大windows 开发者难度