プロジェクト

全般

プロフィール

機能 #817

URLを補足するような情報を取り扱う仕組み

toshi_a 初音1年以上前に追加. 約1年前に更新.

ステータス:
新規
優先度:
通常
担当者:
-
対象バージョン:
開始日:
2016-02-20
期日:
進捗率:

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を表示できるかもしれない。

履歴

#1 toshi_a 初音約1年前に更新

これは思ったのだけど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みたいなので扱うことになるので、マルチサービスじゃんこれ。マルチサービスの側からもう少しよく考えてみる。

他の形式にエクスポート: Atom PDF