kernel 底层配置问题 about chimee HOT 39 CLOSED

@songguangyu 没看到 reloadTimes 啊。。。。

from chimee.

kernels: { comonCofig:{},flv: { kernel： flv, config: confg } }
可以加一个commonConfig 有好的建议可以提

from chimee.

不建议加 common 太麻烦

from chimee.

嗯 有好的建议吗 其实 common的很少，并且可能真正需要的人才会配置这些参数，一般使用默认值就可以。

from chimee.

https://github.com/Chimeejs/chimee/blob/master/src/dispatcher/index.js#L476-L493 调用 kernel 具体逻辑在这里。会将用户单独配置的 config 注入 preset 交付给 kernel。

至于 api 设计。稍后想一下。

from chimee.

嗯 我之前的提议 是尽量使得chimee 的配置不那么臃肿，并且底层更新配置 上层不需要改动。

from chimee.

光宇这边想一下 kernel 接收参数的方法。

交付的对象是

config.preset

或

config.presetConfig

不对用户暴露。

from chimee.

kernel 的配置虽然会统一通过核心的 videoConfig 配置下发，但是用户不会直接接触到。

from chimee.

kernel 核心配置名称在此。

https://github.com/Chimeejs/chimee/blob/master/src/dispatcher/video-config.js#L240

preset 可以更改设计。我们做好版本控制就好。

使用的时候 chimee 会对用户的配置，即 kernels 进行转换。

from chimee.

直接暴露给用户是否更方便，更好维护呢？

from chimee.

不是。你需要的是完整配置，我提供是尽可能简易的 api ，目的不一致

from chimee.

我不需要完整的配置，我配置都有默认值，只有在用户需要的时候才需要配置。我们目前就是如何优雅的提供API 供用户使用，同时也能满足我们内部的迭代和升级。

from chimee.

那是你的默认值，不是我的默认值。我可以只配字符串。kernel 可以提前安装的。你怎么配？怎么满足？

from chimee.

chimee 的配置依然走chimee 的配置渠道，编解码器用到的配置可以单独配置。两者不冲突吧，chimee需要使用到编解码器的配置吗？ kernel提前安装是怎么提前安装？

from chimee.

installKernel, 为了适配你们之前提出的 issupport 支持的。chimee 不需要啊，可是你通过 chimee 暴露啊！ chimee 的配置受你影响啊！

from chimee.

目前kernel都模块化了，用户引用flv 的时候是否可以自行调用flv issupport 来判断是否支持。

from chimee.

另外，没有找到根源的 reloadtime 配置。请提供相关文档或者代码看看这个东西哪里用了。

from chimee.

https://github.com/Chimeejs/chimee-kernel/blob/master/src/config.js

from chimee.

用户还需要遍历你的 kernel 才支持吗？他只想调一个方法啊。

from chimee.

请将公共 api 及其用途也一并列出。

from chimee.

目前不需要遍历吧 比如用flv 就调用 flv issupport 了。不可能在调用hls 和mp4的 issupport 了吧？

from chimee.

目前公用的 并且有用的 应该就这一个

from chimee.

万一都用了呢？那他不是要调用三次？而且你现在只是简单检测。没有针对地址检测。

from chimee.

不要应该，请提供列表。

from chimee.

最好是可维护文档，顶层 api 及模块间接口设计不能随意。

from chimee.

公用的 api reloadTime。
用户目前使用什么格式的视频用户应该是清楚的(个人猜测)。
咱们先讨论问题， 文档可以后续在写吧，一个事一个事来。

from chimee.

没有文档，你讨论不好这个问题。请不要猜测用户。

要不你就按照我的设计设计好 chimee 和 kernel 间的接口。这样你最轻松。我做好转换给你。

from chimee.

如果用户一定要判断，那是否要把判断方法挪到chimee里去？

from chimee.

那你这样说话就不是在交流和沟通了

from chimee.

另外，因为 reloadTime 是 kernel 公用的字段。所以还是要写清楚用法，我考虑下可不可能重复。

chimee 日后会对一定方法有包裹，之前讨论也已经按照这个步骤做了，但是因为 kernel 没提供出来所以没有文档公开。

from chimee.

对的，我的目的不是交流和沟通，我转过来 issue 就是让你认真想清楚这个 api 到底要怎么设计。

from chimee.

OK 我晚上在思考一下。

from chimee.

对于 chimee 层，只为了让用户方便。用户在什么时候需要留意什么 api ，这才是 chimee 关心的点。对于你这种能够分清楚 flv， mp4 等等配置的专业用户，我们是可以全部展开的。但是考虑到一些易用性和上手问题，某些 api 我是做了简化的。这样直接下传 kernel 层，只会让你处理逻辑倍增。

因此我建议，你提供最专业最全量的配置。我帮你隔离问题。

from chimee.

嗯，这种方案有两个小问题，讨论一下怎么处理，hls是外部包，如果这样处理就要锁版本了吧。如果每一次kernel 新增参数都要同步给chimee，然后chimee在发版。这样比如有用户紧急需要一个参数，更新一下底层kernel 就可以快速解决问题，如果绑定在一起的话，需要一起发版 用户的问题才能得到解决。

from chimee.

hls 如果经常发生这种变化需要锁版本。

最后的设计会类似你最初设计的方案。我们会将用户对某个特定 kernel 的配置直接下发，因为对 chimee 无用。这一层可以用于紧急问题解决。

kernels: { flv: { kernel： flv, config: confg } }

但是一些公有参数，考虑到便利性等问题，我们会上移。

并且最重要的是，kernel 有任意改动还是需要知会 chimee。

现在 kernel 的单元测试和 SemVer 的语义都做得不好。在 chimee 这层也是锁了。就算我们 api 很自由，chimee 锁版了更新也是无用的。

所以最重要还是整个系统各环节的质量和稳定性。特定的自由度还是会留下来的，但切忌滥用自由。

from chimee.

OK 我觉得没有问题，SemVer 的语义 能帮忙提提建议吗？我更改一下。稍后单元测试会补全，最近一段因为还处于大量的开发阶段，还有很多功能没有完善，所以版本迭代比较频繁。后续改动都知会到你这边，主要是保证项目的稳定性。
公有参数目前不多，我整理一下，稍后会在楼下列出来，或者给到链接。
底层不规范的地方，欢迎多多指出。

from chimee.

建议在 chimee-kernel 价格文档，link 到这吧。毕竟这块主要还是你维护。

你先列出你期望中的 kernel 的 api ，特性等。每次发版根据你对相应功能的修改判断就好。

详细阅读这篇文章。

大概原则可以这么理解：

1. api 无变化，patch
2. 有新增 api，但并不影响原有应用。极小范围的更改且向后兼容。minor
3. 大改动，有 api 废弃等。major

from chimee.

另外，chimee-kernel 先把我昨天的修改和李喆明的修改发版吧。

from chimee.

@songguangyu semver 可以简单的按照 重构.特性.修复 这么来理解。

from chimee.