eniehackとの議論5

Twitter proxyに関する2022/08/05 sei0oとの議論4 - およそMECEでないアカシックレコードの200那由多飛んで3万分の3への返信

• standalone

  • と思ったが、下図のようにbackendとfilterを分離したdaemonとして動作させても、コードベースが分離できてメンテナンス性がよさそう

  • Filterを使わない人にとっても、Twitter APIを触りたくない人的にはbackendだけを使うこともできて汎用性が出そう

    • わかるなあ
    • nitterがREADMEに「いずれDeveloper API提供したい」って書いてたから、それをbackendにするのはアリだなあ、と当初（twitter proxy 実装原案）考えていた
    • 後回しにしよう

• mruby

  • APIに手が加えられておらず、内部的な改善がなされている可能性も……？

    • なるほど？
    • 2.1.0をサポートするPR は出てるなあ

  • mrustyは、tarで固めたものを解凍して運用してそうなのでカスタマイズができない……。

    • forkして get_mruby.sh を書き換えてしまうのは解決にならない？
      • 具体的には、./minirake (=Rake) を呼び出す前に改造したbuild_config/ を入れる

  • そういえば、mrubyってbuild時に組込むgemを指定し、それ以外のgemはrequireできないので、IOとSocketをbuild parameterの設定によっては排除することができそう

    • それなら、 default-no-stdio.gembox を使えば十分っぽいね
• luau

  • けど、開発は活発そうだし、開発が停滞するかどうかを考える必要は現状ではなさそう（？

    • 同意

  • replaceするコストがどれくらいになるんだろう……？

    • backendとやりとりする部分は（backendとfilterが同じプロセスで動くのであれば特に）そんなに大きな変更は必要なさそう？？
    • むしろreplaceするまでに（願わくば）蓄積されてきたLuauフィルタをどうすんねん、という課題が出そう
• 自分はRubyに馴染みがあってより直観的だと思っているのでRubyで書きたい
• 一方でLuaもNeovim等で活用されているから、それでもいいと思っている

• 若干議論が収束してきた感
• リポジトリを今後つくるにあたって、なんかいい名前ないすか
  • bokunokangaetasaikyounotwitterclient
• リポジトリどこにつくろう
  • MSの犬なのでGitHubでいいやとか思ったけど、nakaya君面白いの知ってそう