2022/08/03 sei0oへの返信2
#ぼくの考えたさいきょうのTwitterクライアント
2022/08/02 sei0oへの返信の続き
往復書簡になってきて笑う
わかるよ
新鮮でおもしろい
Twitterなどのマイクロブロギングではここまでスムーズに行かなそう
細かい差異はあるけど一緒にやってもいいんじゃない？という気がしてきた
差異はあれど、初期の共通部分はかなり合致してそうね
Rustの経験がないので、開発効率的には微妙かもしれんけど、参加したさはあるね
実装形態は固めたほうがよさそう（それはそう）
Webを使うのか、standaloneで実装するのかなど
UI
サービスとして考えるとUIは普通（Play Storeにあるような）のにすればいいと思った
普通のGUIとは……？
Frontend <-> Filter <-> Backend という分離ができると気持ちいいだろうな
Front <-> Backend(Filterが内包)みたいな想像してたけど、綺麗に分離できるならそれでもいいかも？
フィルタ
もっと一般的に加工させてもいいと思った
Regexでreplaceできるのはよさそう
Filterは単一のpost -> 単一のpost?という感じの型になるのかな？
細かい話: passしたい場合はpostかtrueを、dropしたい場合はnilやfalseを返せばいい感じ……？
フィルタはステートレスを前提と勝手にしてたな
gtkで実装するなら、増分を送る方式のほうが速度は少しは出そう
リモートのAPIを叩かせようとすると、それはそれでセキュリティ的に考える必要がある
Filterにはpostと最低限のライブラリを与えるだけでいい気がする
細かい話: ネットワーク系ライブラリ、低レイヤが触れそうなライブラリはrequireできないようにするなど
提案: Filterが複数重ねられるとよさそう
Filterの定義の他にtimeline定義のDSLが必要になる？
細かい話: ぼくの考えたさいきょうのTwitterクライアント#62e8047e8b8fcb00002066ca を機能とする場合、atomでfilter名（TL名）が定義できるとうれしそう
想定としては、TweetDeckの列1つ1つにsocketを作れると柔軟になってよさそう？的な
Rubyなら magnusとかどうでしょう
mrubyが理想だけど、情報が少ないので、先に普通のRubyで動作させてから移行してもいいかも
余談: 一応、mrubyにも書籍は幾つか出てて、こういうのもある
magnusは普通のRubyをRustと協調させるという認識でok？
細かい話: このライブラリはomitしたい、みたいなのはできるんだろうか……？
マルチプラットフォーム対応
Fediverse各種のデータ構造の共通する部分はActivityPubに入っているはずなので、ActivityPubと Tweetのデータ構造の共通部分を抜き出して、差異は別途フィールドを設けて吸収させる感じかなあ
1つのschemaに落とし込むのはよさそうね
抽象化レイヤがややこしくなりそうだ……
提案: 後に回したほうがよさそう
GUI
ここはgtk-rsでもいいかも