機能 #1164
完了Score
0%
説明
現在、TwitterのExtended Entityを参考にした本文の部分文字列にリンクを貼るための仕組みがあり、IntelligentTextViewやMiraclePainterが利用している。これを現在のEntityの反省を踏まえてSlackやMastodonなどのモダンなWorldでの利用に耐えるような機能拡充を行う。
解決したい問題¶
Entityの各項目がHashで記録されており、各値の意味が明確でない¶
Hashにリンク先のURLなどを含んでいるが、TwitterはなんとかURLみたいなフィールドをいくつも返してくるうえ、mikutterも用途が曖昧なフィールドをいくつも追加している。適用位置、表示文字列、リンク先URLの3つさえあれば良いはずなので、ほとんどのフィールドが利用されていない。
プラグインシステムと親和性が低く、拡張性がない¶
DivaにEntity機能をモンキーパッチして埋め込んでいる。
また、そのModelを定義しているプラグインがEntityまで考慮しなければならなくなっている。例えば「ツイートに "@toshi_a@social.mikutter.hachune.net" というフレーズがあればMastodonのユーザページへのリンクとして扱う」というプラグインを書くことができない。
更に、Entityは特別なオブジェクトとして一部のMessage Modelで提供しているだけなので、Entityによって改変された本文を得る方法が複雑になっていて、標準プラグインでもActivityプラグインなどはこれを利用できていない。
たんなる装飾、画像埋め込みに転用できない¶
Entityは単純に文字列の特定の位置が外部URLへのリンクであることを示すためのものだが、SlackやMastodonのカスタム絵文字を新たに実装してしまうと既存のEntityの仕組みと衝突する。
添付ファイルとの関係が曖昧で、扱い難い¶
現在mikutterのMessage Modelには添付ファイルを示すための共通の概念はないが、Twitterのようにツイートの中に添付ファイルのURLが入っているWorldは稀なので、これにアクセスする手段を提供できない場合がある。
一方でMastodonは画像を添付して専用のフィールドで表現した上で本文にも画像URLが入っていることが多く、 https://d250g2.com/ などの糞サイトやOpen Graph対応サイトの埋め込みなども考えると、厳密には添付ファイルとEntityの区別は曖昧なものである。Entityを作り直すにあたって、添付ファイルの問題の解決も視野に入れる。
ファイル
関連するチケット