2022/08/05 sei0oとの議論4
アーキテクチャ
standalone
backendとfilterは同一のdaemonで動く？
そうね、同一のbinaryで動作することを想定している
と思ったが、下図のようにbackendとfilterを分離したdaemonとして動作させても、コードベースが分離できてメンテナンス性がよさそう
Filterを使わない人にとっても、Twitter APIを触りたくない人的にはbackendだけを使うこともできて汎用性が出そう
我々はfilterができるクライアントがほしいので、蛇足感はあるけど
https://scrapbox.io/files/62ebdee0ceabd3001d8a6f36.png
sei0oくんの考えているWeb版とは異なり、Filterはvimなどのエディタで直接編集することを想定している Syncthingはdaemonを置いて、localhost上のWebサーバでGUIを提供してるなあ
整理
よさそう
マルチプラットフォーム化
フィルタ
mrubyをRustで使うためのbindingsがどれも若干古いのが気になりますね…
APIに手が加えられておらず、内部的な改善がなされている可能性も……？
参考:
buildする際にgemをbundleする設計だったりするので、mrubyを扱うライブラリを作るのが難しいというのがある……。
mrustyは、tarで固めたものを解凍して運用してそうなのでカスタマイズができない……。参考 そういえば、mrubyってbuild時に組込むgemを指定し、それ以外のgemはrequireできないので、IOとSocketをbuild parameterの設定によっては排除することができそう
参考:
Luauは企業が作っているのか、なるほど
開発が停滞したときにカスタマイズであるが故にreplaceが必要となる事態にならないか心配になった
けど、開発は活発そうだし、開発が停滞するかどうかを考える必要は現状ではなさそう（？
個人の感想: mruby推したいけど、Rustと組み合わせるという観点ではLuauになりそう……？ rubyでFilter書きたい気持ちもあるけど、後でluaからreplaceするとかでもいいかも？
replaceするコストがどれくらいになるんだろう……？
FilterをBackendからはがすなら、FilterをRustでない言語を使う選択肢も……？
sei0oくん的にはFilter言語はどれがいいんだろう？