使用 go-bind-plugin 真正實現插件化管理可行方案

[eric2788]

目前編寫插件需要透過腳手架，也就是最後依然要 developer 自己 compile 成 exe。 假設一個用戶想同時擁有安裝兩個訂閱插件，但兩個 訂閱插件分別來自不同的 開發者，那麼可能會出現同時使用兩個exe的情況？ 又或者需要從源碼提取這兩個訂閱插件，然後放到新建的腳手架再進行 compile， 個人認為對於用戶來說不太方便。

而透過 go-bind-plugin，它能透過動態載入 .so 文件實時加載libraries，即可以在 .exe (executable) 形態的時候在 runtime 加載插件。

理想架構是這樣

• DDBOT.exe
• plugins/
  • twitch.so
  • bilibili.so
  • twitter.so
    ...

以上目前只是一個理想方案，尚未進行過任何的測試，所以不知具體效果會如何。如果你沒有太多時間，我是打算有空的時候嘗試研究修改並遞交 PR，不過如果你不考慮這個方案，那我就不花時間研究了

[Sora233]

目前編寫插件需要透過腳手架，也就是最後依然要 developer 自己 compile 成 exe。 假設一個用戶想同時擁有安裝兩個訂閱插件，但兩個 訂閱插件分別來自不同的 開發者，那麼可能會出現同時使用兩個exe的情況？

最后要developer自己compile，是的，但是并不是需要两个exe。

本质上插件部分和运行bot的部分是分离的，我们可以看一眼脚手架中main.go的部分，它只是一个bot的入口：

func main() {
	// 使用默认的日志格式配置
	DDBOT.SetUpLog()
	// 启动bot，会自动阻塞
	DDBOT.Run()
}

而实现是：

DDBOT/bot.go

Line 55 in d03e748

func Run() {

anyway总会需要一个entrypoint去编译，脚手架只是为了方便测试而带上了这一部分，如果想要再引用其他开发者的插件，只是需要import 一下，重新编译即可，并非需要编译两个仓库内的main.go：

import (
	_ "github.com/Sora233/DDBOT-example/concern"
)

---

而透過 go-bind-plugin，它能透過動態載入 .so 文件實時加載libraries，即可以在 .exe (executable) 形態的時候在 runtime 加載插件。

关于动态库形式的插件我在初期也做过一些尝试，考虑过官方的go plugin和hashicorp/go-plugin，由于他们的一些特性（绑定go版本的传染性，以及本地rpc的端口占用）我认为并不适合ddbot。

而当前的ddbot已经不能方便地使用动态库形式的插件，因为ddbot使用的数据库是 buntdb，它并不带有网络协议（即不支持多客户端访问），也不支持文件锁（即不支持多进程访问）。

所以当你在尝试动态库形式的插件方案的时候，也请注意插件内访问数据库的问题（你会选择更换新的数据库吗？）。

[eric2788]

是我失策了，并没考虑到那么多。我就单纯考虑到不知道go有没有可能实现类似 mc 插件那种管理方案，毕竟考虑到使用机器人的不一定是开发者，如果他们想安装新的插件可能就需要不使用原版，并需要透过开发者的协助安装一个新的编译版本。

关于数据库的问题？我自己并不太想到一个新增订阅的插件有什么需要手动接入数据库获取数据的情况 umm

[eric2788]

@Sora233 問一下，我可以直接透過PR遞交來新增訂閱源嗎？

插件化管理先放一邊，目前的這種方式對開發者來說確實算方便
你的想法是從透過 go get 不同的 pkg 再 import 到腳手架直接編譯
但我覺得有很多ddbot使用者大多不是開發者，他們可能沒有go環境甚至不會clone源碼
如果他們要新增兩個來自不同開發者的訂閱源，就需要其他開發者熟人請教或者等官方支持，對他們來說確實有點不太方便

所以我目前比較希望透過遞交PR來新增訂閱源

[Sora233]

一些公共网站想要作为新订阅源加入ddbot official repo 是合理和可接受的，短期内还可以接受加入这个repo本身，也可以考虑建立一个插件repo。
但实际情况是有并不适合加入ddbot official repo的插件，这可能是因为它们并不适合其他人或者广泛使用，举一个例子：我有一个游戏汉化组，会使用ddbot每日推送汉化进度，并且进度数据是通过内部平台api获取的，显然这个插件并不适合其他任何人使用。

你描述的非开发者的使用场景确实存在不便，但并非只有ddbot会面临这个问题，一个通常的方法是创建一个github action repo，非开发者可以使用配置的方式定制插件，然后使用github action workflow去编译适合的程序，不过我不认为目前对于非开发者的优先级有太高。

pr只要通过review的话都会接受，并不只限定订阅源，其他合理改动也ok。

[eric2788]

好的，我目前想新增的是 twitcasting，听说国内也能直连，或者如果你有空的话.... https://github.com/twitcasting/twitcasting-api-go

[eric2788]

其实.....非开发者也不一定会用github action repo, 不过既然你说优先级不高（应该是指没打算优先支援非开发者？），那就算了