topic/1326-mastodon ブランチで開発していきます。

RESTとStreamingが排他になっているが、mikutterの考え方ではRESTは常に動かしていたほうが良いかも。

また、投稿完了のレスポンスやリプライをホームTLに突っ込むなど、データソースとAPIエンドポイントを一対一で考えるのではなく、経路問わず取得できたデータを適切なデータソースに流す。

データソースがAPIと一対一になっていない理由¶

• サーバのトラブル等で特定のエンドポイントだけが死んでいたりすることがあり、そのときに生きているAPIだけで可能な限り使えるようにするため。
  • Mastodonではそういうこと無さそうだが、他のサーバのLTLから自分のHTLを部分的に提供するといったことは可能

RESTが常に動いている理由¶

• Twitterでは、UserStreamだけ停止する、接続はできるがイベントが送られてこないといったことがあり、どちらも信用できなかった
  • 半端に取りこぼすこともあって、UserStreamでは全てのツイートを受信できている保証はない
    • とおもったらだいぶ後になって送られてきたりな…
  • Mastodonでは大丈夫そうだが、やってはいけない明確な理由がないならmikutterらしい仕様にしたい

いずれも賛成です。
WorldonでAPIとdatasourceが一対一になっているのは、単に実装が楽だからです。
現在ではフォロー一覧やリストのメンバー一覧のような情報もworldに持たせていたと思うので、適切なdatasourceにそれぞれ流すことはそれなりにできそうです。FTLだけは無理がありそうです。

インスタンス管理者視点だと、ストリーミング機能だけnode.jsで提供されているので、アップデート時に何らかの理由でnode.js側だけがコケて、解決するまでとりあえずRoR(=REST+WebUI)だけ動かしておくようなズボラな管理者は存在するかも知れません。逆にnode.jsだけ動かす場合は、投稿も出来なければActivityPubに反応もできないので、意味が無くなります。

ところでふと思いましたが、worldのマイグレーション以外にも抽出タブのマイグレーションが必要そうですね。

sse_clientについては一応汎用なつもりで作りましたが、Mastodonでしか動作確認していませんし、この分離方針で問題ないと思います。
ただ、イベント名をsse_*プレフィクスから別のものに変えておかないと、Worldonと共存したときに二重のコネクションが張られると思います。mastodon_sse_*プレフィクスあたりが妥当でしょうか。

ところでふと思いましたが、worldのマイグレーション以外にも抽出タブのマイグレーションが必要そうですね。

他にもマイグレーションできるものとしてはcommandなどもあります。

sse_clientについては一応汎用なつもりで作りましたが、Mastodonでしか動作確認していませんし、この分離方針で問題ないと思います。
ただ、イベント名をsse_*プレフィクスから別のものに変えておかないと、Worldonと共存したときに二重のコネクションが張られると思います。mastodon_sse_*プレフィクスあたりが妥当でしょうか。

既にこの方針で実装しているのですが、なんか動かないなぁ

SSEも受信できるようになったのでだいたいこれでOK。残りは別のチケットでやったら良いかも。

Worldon Worldのアカウントをいい感じに引き継ぐ　について¶

#1329 でWorldonをアンインストールしてもMastodonプラグインが残るようになったことから、手動でのアカウント引き継ぎが現実的になった。
自動的にやる場合は、Worldonプラグインを機能毎にプラグインに分けた後、それぞれのプラグインに対してどのようなデータ移行が必要になってくるか検討する必要がある（抽出タブとか、コマンドショートカットとか）。

最も問題になるのがデータを移すタイミングで、起動したら必ず移すのか、Worldonがアンインストールされていることを検知してやるのか、などわりと悩みどころが多い。
いっそ何もやらないほうがわかりやすい気もするので、別チケットにするか、一旦ペンディングにしてもいいかも

先に、APIリクエストを全てDeferredを返すものにしておきたい。
呼び出し側がメソッドを使うときに毎回Threadを使うべきか判断しているのでミスが発生しそう。