iTunes入れてみた

日記

しっかし、音悪いなー iTunes 視聴の時には音質が悪いのかな？
日本のメーカがiTumesに勝てるためには、おそらく共通のダウンロード基盤が必要なんだろうな。

  • サーバ上で一度購入したものはずっとダウンロードし続けることができる
  • どのメーカーの端末でも一度購入したものはダウンロードできる
  • 端末に依存しない。

等の条件、つまりiPodという端末販売によって成り立っているAppleのビジネスモデルを集団で壊さないと未来はないのだろう。
逆に著作権者側というか販売者側は共通の基盤によってappleの圧力から逃れることができるようになる。
どうせ護送船団方式ならこれぐらいやって見せればいいのに。
RFP一個作ればいいだけじゃんか。
ついでに映画（邦画）もこのパターンで売れるんじゃないかな？
ハリウッドはリビジョンコントロールによって小出しに儲けているというか投資のリスクつまり投資の量と回収の量をコントロールしているわけだけど、邦画の場合、所詮回収は一発のみなのだからやれそうな気がする。

  • だれが購入しているというフラグ
  • コンテンツを盗まれないための基盤（任意のデバイスでしか再生できない）

さえあれば、今の収益性を丸々崩さずに（CD屋・映画館は除く）モデル構築ができるんだな。
要は権利のあるなしというフラグを抽象化して共通基盤にしてしまえば十分なのか。ん？認証に近いな。

  • コンテンツのIDを購入したことを示すIDをサーバに送る
  • サーバ上でIDと購入したことを示すIDを比較し、視聴許可IDを返す。
  • クライアント側で視聴許可IDを使ってコンテンツを展開する。

んー公開鍵暗号系みたいだ。
と、いうことは 利用者のIDからコンテンツIDを演算する＝購入済
そこで集合化されたコンテンツIDから視聴許可IDを集合で利用者に返送できるようにすればいいのか。
ということは、利用者のIDとデバイスのIDがマッチする必要がある。
ん？まてよ。
利用者が複数のデバイスを使うことを肯定して物事を考えていくと。
提供者側はどうしても単一のデバイスでサービスを提供したがるのだが、利用者は目的に応じた多数のデバイスを利用するのが本当だ。
（例：宮大工は必要に応じて複数の鉋を利用する）
デバイスでコンテンツを加工してデバイスの特性に応じたコンテンツに変化すればいいのか。
(利用者ID+コンテンツID)->(コンテンツ)->(必要な情報)
なるほど、一番左の括弧はリクエスト　真ん中はサーバでのストレージ　右がデバイスが行う作業となる。
現在は必要な情報への加工はサーバサイドで行うようになっている、つまりデバイスの特性による判断はサーバ側であるといえる。
ディスプレイの大きさに限界があるように、デバイスへ送信されるコンテンツそのものには物理的な限界がある。ネットワーク、表示領域の大きさ。
とすると、コンテンツを群で捉えた場合、データ転送量に限界が出るわけでここの整理が残ってるか。
おそらく、コンテンツへの単体アクセスと群であるアクセスには差異があるわけで群アクセスの時のアクセス様態をもう少しつめる必要がある。
単体アクセスは基本的にデバイスで十分なはずなんだ。
もう少し考えてみるか。