下一个需求是什么? 我看看板已经做好了
相关帖子
- 其他回帖
-
YesMrs •作者
我觉得你说的核心问题是插件开发过程中确实有很多可能官方不支持的功能。这些功能如果官方在原有的内核基础上包装出来,即可以解决这个问题 我觉得不太需要官方去写插件 关键是插件和官方需要有一个地方进行提需求交流。不过我觉得说实话,如果是插件作者提出的一些需求, 官方确实应该优先支持 作者提出的需求一般是某些接口之类的东西。这种实现起来简单, 然后其他插件作者也可以用, 有问题大不了就不用插件即可。感觉需要一个专门的 git issue TAG.
1 回复 -
“插件”只是个说法,并一定就完全和本体分开。官方插件和本体一起打包就可以规避掉版本的问题。
性能方面我理解都是调用内核接口,还是得看场景,不一定插件就更低。
内部函数和方法不需要全暴露。官方尝试以“插件”的形式来实现功能,更容易意识到可以提供哪些 api 给插件开发者,丰富目前开发者文档。同时有官方插件库给新手参考。
我的想法是官方能以带头做插件的契机,将开发社区活跃起来(通过维护官方插件的方式变相参与本体的维护)(这可能是我一厢情愿),对 dv 维护的负担小些,对于一个开源软件来说可以吸引更多人参与(通过解耦降低了阅读本体源码的门槛)。理想情况下就会“什么都有插件来做”而不是“什么都交给插件来做”。
我看到不少有能力的开发者自己 fork 一套代码改了一些功能自己用,如果能把这部分改动回馈到社区就好了。
问题可能在“官方插件”的形式加重了目前 dv 的负担。本来可以直接内部改改就实现的逻辑需要多考虑一层。短期来看都是痛苦,长期来看也不一定有益。
对用户来说思源的开箱即用,本体就很强大是优势,挺好的。我个人也乐于本体强大些。一个项目有维护者们自己的偏好,方向不在这也没啥。
1 回复 - 查看全部回帖
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于