eniehackとの議論7

両方というのはluauとmluaの連携？

• luauとRustの連携、mrubyとRustの連携、の両方を試すべきかなあ、という意味だった

luaAPI(=Rust側)のwrapが、どのレベルなのかにも依りそう

• これだよねー、どっかで実験せねば

• …その後1人用・マルチアカウント（ソース）というので考えてる

• とりあえずUNIX domain socket（Rustなら UnixStream かな）を使う?
  • socket上にjsonを流すのってプラクティスとして良いのかなわからん
• gRPCとかではない？

• 以前「frontendはTwitter APIが話せる必要がないけれど、かといってbackendがすべてwrapするのもつらい、一部frontendに移譲していいかも」という話があった
  • タイムラインはフィルタ処理を通す必要があるのでbackendでwrapしてやるのが絶対
  • 他にwrapしたほうがいいのってなんだろう
    • 作ってからwrapしたくなるケースがありそうで、そうするとまた互換性が困りそう
      • 例：lists/tweets （リスト中のツイートの意; 実在しない）エンドポイントをフィルタするようになった
        • list = call_api("lists/tweets/", arguments...) と書いていたところを、list = get_filtered_tweets_in_list(arguments...) とするような仕様変更
        • このとき変更前に書かれたfilterからの lists/tweets に対するcall_api 呼び出しを get_filtered_tweets_in_list にbackend側でリダイレクトするようにすれば、filterの変更は必要ない
          • が、あまり良い策ではなさそう…
      • バージョン管理？
        • なんらかのメタデータはいずれにせよ用意する必要があるなあ
          • GreasyForkの例 スクリプト先頭の @author などに相当する項目
      • 考えすぎ？
• frontend -> backend
  • A) （フィルタされた）ツイートを読み込む
  • B) 任意のエンドポイントについてリクエストを依頼する
  • etc…
• backend -> frontend
  • a) Aに対して返信＝ツイートのリストを送る
  • b) Bに対するレスポンスを返す
  • etc…

• CUIで、生のメッセージを読み書きできるようなやつ
• frontendを作る上でのリファレンス実装にもなる

• ソースコード中に

• よくあるのはお互いのアイコンをつけてコメントしていくやつ
  • [sei0o.icon] ↑これ難しそう みたいな
• でもこれコメント増えたら面倒そうだよなあとか思う
• フロー（議論）とストック（整理）？