要約

  • Web Intentsは、ウェブサイトが「写真を編集する」という仕事だけを指定し、どのサービスに渡すかをブラウザーと利用者が決める仕組みを目指した。
  • Chromeは2012年に実験版を安定版へ載せたが、サービス登録はChrome Web Storeのアプリ用マニフェストに限った。GoogleはChrome 24から実験を無効にし、W3Cは2013年に勧告化を止めた。

写真サイトは編集者を雇いたかった

Chromiumが2011年8月に示した例は、編集機能を自作する資金のない写真保管サイトだった。通常なら自分で道具を作るか、特定の編集サービスと個別に接続する。Web Intentsでは、サイトが写真と「編集」という作業をブラウザーに渡す。ブラウザーが対応するサービスを探す。共有や表示も同じ仕組みの対象だった。小さなサイトにとって、機能を増やすたびに相手と契約しなくて済むという話である。

W3Cの文書は、依頼するページ、仕事を受けるサービスページ、両者を仲介するユーザーエージェントを区別する。サービスは扱える動作とデータ型を登録し、ブラウザーは候補を照合して利用者の選択を受け、結果を元のページへ返す。文書は通常のリンクとの違いも説明した。リンクは行き先を先に決める。Intentは仕事を先に決め、行き先は後で選ぶ。送り先を決める力が元のサイトから移る。

誰が候補を並べるのか

仲介を引き受けるブラウザーには、登録と選択の規則が要る。案では、サービスは自分と同じオリジンの処理ページだけを登録でき、動作とデータ型が依頼と一致しなければ受け取れない。新たに見つけたサービスへ送る前には利用者の具体的な操作が必要だった。依頼元のページは、利用者が登録したサービスの一覧をこっそり取得できない。毎回メニューを開かずに済む初期設定は認めても、利用者が配送先を設定できることが前提だった。

この仕組みでは、ブラウザーが仕事の案内所になる。写真を預かるサイトは提携費用を減らし、編集サービスは候補に載りたい。利用者は自分の写真がどこへ行くかを見極める。選択画面の作り方は市場の入り口そのものだった。

安定版に入った実験

2012年5月のChromiumの発表によれば、試作機能は当時のChrome安定版へ入った。ただしAPIには実験を示す接頭辞があり、将来の変更で互換性が失われる可能性もあった。さらに、サービスの登録はChrome Web Storeアプリのマニフェストからに限られた。成熟後にその制限を外す予定だった。開かれたサービス発見の実演は、ブラウザーのストアという狭い入口で始まった。

その条件は試験を管理しやすくする一方、普通のサービスページが自分で登録して競う状態を再現しない。誰が選択肢に入るかをChromeが先に決めていた。

2012年11月1日、GoogleのGreg BillockはW3Cの公開メーリングリストに、Chrome 24から実験機能を無効にしたと報告した。APIとChrome固有の利用体験の双方に課題が見つかったという。利用率や単独の障害原因は示していない。数か月前に開発者を招いた試験は、そこで止まった。

文書は残り、勧告化は止まる

2013年5月23日のW3C作業部会ノートは設計を記録しつつ、勧告を目指す作業を進めないと明記した。相互運用試験も実施されていなかった。同年6月のW3Cの報告は、利用者とのやり取りにどう組み込むかという懸念が未解決で進展が止まったと記した。頼みたい仕事はあった。受け手をどう見せ、どう選ばせ、どう信頼させるかが難しかった。