機能 #817
未完了URLを補足するような情報を取り扱う仕組み
0%
説明
Mediaには、画像の場合だと枚数がまちまちで、順番がある。また、解像度やビットレートのような、同じMediaでも複数のVariantが存在する場合がある。
Mediaに限らず、通常のWebのURLや、ツイートのパーマリンク、ユーザページなど、幅広いパーマリンクを扱えるようにして、現在のmikutterではStringでURL一般を扱っている。上記のような情報を扱うためにはURIでも不十分で、独自のデータ構造で扱うようにする必要があると思う。
したいこと¶
適当にURLを投げたら開いてくれるopenイベントを定義¶
例えばWebのURLならブラウザを開くし、Twitterのユーザページならプロフィールタブといった具合。実際にこれをやるなら別チケットに分けるが、事前に本件のような仕組みが確立していると便利だと思う
複数枚画像の前・次¶
4コマ漫画などをコマ毎に1枚の画像にしてアップする人が増えているので、1枚ずつ開閉をするのが面倒。一枚目を開いたら前後にページングみたいなことができると良いと思う。
種類¶
TwitterのEntityオブジェクトでは現在以下の値が扱われる。
- photo
- video
加えて、以下のような種類もサポートしたい。
- url (Web上のリソース一般)
- audio (Sound CloudやPiaproなどのURLが貼られる場合)
- message (Messageのpermalink)
- user (Userのpermalink)
- list (他人のlistとか表示する機能ができたらええなぁ)
- search (Twitter検索・ハッシュタグにも使えるか)
class Mikutter::URL::Web << Mikutter::URL::Base
Media Variant¶
photo¶
Twitterのphotoは現在
- thumb
- small
- medium
- large
- (orig)
があるとされている。それぞれ幅、高さ、リサイズ方法が取れる
class Mikutter::URL::Photo << Mikutter::URL::Base attr_read :width # Fixnum attr_read :height # Fixnum attr_read :resize # String attr_read :mimetype # MIME::Type
video¶
videoにはphotoも含まれていて、そのphotoがサムネイルということになっている。
video自体はアスペクト比、ビットレート、mimetype、動画自体の長さが取れる。
基本的にはmp4動画だが、驚いたことにMPEG DASHやWebmなんかも返してきてる。ひょえー。
class Mikutter::URL::Video << Mikutter::URL::Base attr_read :thumbnail # Mikutter::URL::Photo attr_read :duration # Number (seconds) attr_read :aspect_ratio # (ArrayとかRationalとか) attr_read :mimetype # MIME::Type
複数のVariantをまとめて扱うコンテナ¶
photoとvideoには複数のvariantがあって、ユーザの操作なんかで切り替えられる必要がある。そのため、同じContentsだが違うVariantを指すものをまとめるコンテナみたいなものが必要になってくる。
URLとしてこのコンテナを使うことができれば、単一のURLから
画像をインライン展開するサードパーティプラグイン → 最小のvariant
openimg → 大きなサイズ
画像をダウンロードするサードパーティプラグイン → 原寸
といった具合に、必要に応じてMediaを取り出せる
class Mikutter::URL::Variants << Mikutter::URL::Container include Enumerable def [](variant)
(PhotoVariantsみたいなサブクラスがあったほうがいいかも)
複数個のMediaと順序¶
違うContentsだが同じTweetに添付されていたなど関連するMediaをひとまとめにしたコンテナもあるとopenimgで4コマ漫画を見るのに便利だと思う。
配列で渡すより
- (photoの場合)クリックされたURLはどれか、という情報を保持できる。ユーザはちゃんとクリックした画像が表示されるし、前後の画像も開けるようになる
- 複数のURLに対応していないようなイベントに渡す場合でも、上記のような情報があるから移譲していい感じになりそう
みたいなメリットがありそう。
class Mikutter::URL::Group << Mikutter::URL::Container include Enumerable def primary
Tweet¶
全てのURLは親URLを持つことができると良いと思う。例えばphotoの親としてTweetのURLがあれば、openimgのウィンドウに、画像と一緒にTweetを表示できるかもしれない。
関連するチケット
toshi_a 初音 さんが8年以上前に更新
これは思ったのだけどRetrieverではないか?
ただし、(現在の)Retrieverをそのまま利用しようとするといろいろと問題がある
- 確実にpermalinkを取得できる(Retriever#permalinkは無く、UserやListではpermalinkを持たない)
- 必ずID値が必要。しかも現在は数値。
- 中央管理の必要がない場合でもRetriever.newできない(URI一般にはIDがない(URIが一意)しそういう管理方法はナンセンスでは)
- mikutter自体が、1ツイートが一つのMessageに紐付いていることに依存しているのだろうか
とすると必要になるのは
- findbyidは削除して、Retrieverのサブクラスたちで実装していくのが良さそう(idからRetrieverを引いてきたい場合、Retrieverの種類は分かっている)
- IDを必須でなくする。
- IDありのRetrieverはそういう感じのMix-in作ってなんとかしてみる。これで既存のRetrieverは引き続きfindbyidが使える。
- 同一性の判定にはURIを使う
- permalinkから適切なRetrieverのサブクラスのインスタンスを検索・取得する仕組み。Retrieverのクラスが分かっていなくてもこれでどうとでもなる。
結局サポートされていないURIはデフォルトのRetrieverみたいなので扱うことになるので、マルチサービスじゃんこれ。マルチサービスの側からもう少しよく考えてみる。