2022/08/04 sei0oへの返信3
#ぼくの考えたさいきょうのTwitterクライアント
2022/08/03 sei0oへの返信2、eniehackとの議論3の続き
往復書簡スタイル
トピックごとにスレッドが立たないのはメリットでもありデメリットでもあるな
これはそう、スレッドにはスレッドのよいところがある
scrapboxだと1つ1つを残しておかないとだしな……
それこそMLがいい感じある（？！
実装形態
普段スマホから見てるんで、早い段階で使用感を試すために、若干webに気持ちが傾いている
スマホからも使えるのはよさそう
どんな形式であれ、「socketでの通信方式はどうするんだ」みたいな問題をすっとばせそうでもある
WebだとFilterの読み込みをどこにするんだろう？
スマホでFilterを読み込むのは面倒そうな気がしている
鯖側にeditorを置く感じになる？
standaloneのときの構成がまだよくわかってないな Twitter APIを叩く、filterを管理するのは誰？
普通にlaptop（自分のマシン、同時にClientも動かす）にdaemonを走らせるイメージを持ってた
socketは基本的にlocalで利用される
細かい話: systemdでのper-user serviceで動かすイメージでいる
私の想像としては、Twitter APIを叩くのはdaemon、Filterを管理するのはdaemon
postの取得し、Filterにかけたpostsをclientに提供するのがdaemonの仕事という認識
図としてはこんな感じ: https://scrapbox.io/files/62eb40467757d5002014d039.png
こっちのほうが、解決すべき設計上の問題は少ないように私は思う
Webで作るのもありなので、この辺の差異に関しては、コアとなるFilter機能がある程度完成してからでもいい気もする
socketの通信が読めさえすれば、frontendとしては問題ない
余談: 極端な話、frontendがbackground processなbotでもいい
もちろん、GUIアプリとしても、TUIとしても、localhostなWebサーバとしても、走らせることは可
UI
あ〜分離ってのは、それぞれのパーツが独立に交換可能ってのを考えてた。実装上はフィルタがフロントエンドかバックエンドに含まれますね
それぞれがmodulableなのな理想よな
Twidereとかofficial Twitterとか、そういうの
よさそう
フィルタ
FilterResponse::AddCW(cw: String), FilterResponse::Delete, FilterResponse::Pass … のようにフィルタが取れるアクションを絞ってもいいんだけど、自由にpost全体を操作させるほうが実装も楽だし面白いフィルタが作れるんじゃないかと考えた
同意
それは当初から考えてたしそれがいいと思う。こういうことですよね：
私が想定してたのはこれですね
それともこっちか？ （これおもしろいな、AppleだったらSmart Listsって名付けてそう）
Ruby
requireの制限とかはできなさそう、そういうのができるラッパーが果たしてあるのか…（mrubyなら？）
mrubyもomitできないが、mrubyが機能が少なく、3rd-partyのmrbgemに投げる思想になっている感じになっている
バニラなmrubyにもSocketクラスがあったりするので、機能を削がれたものを使いたいのであれば、素のLuaを使ったほうがいいかもしれない
マルチプラットフォーム対応
いまさらだけど、「クライアントのマルチプラットフォーム対応（iOS, Windows, Web, etc.）」と「マルチFediverseプラットフォーム対応（Misskey, Mastodon, etc.）」が混ざりそう
思いつき: 後者は「マルチソース」と呼べそう？