Experts.jp日本に、もっとエキスパートを。Worker[1]」ですが、その先行実装が落ち着いてきた今夏、仕様に対する提案や今後の方向性などについて話し合うF2F(Face-to-Face)ミーティングがサンフランシスコで開かれました。Workerの最近、そしてこれからの論点をいくつか解説してみたいと思います。Workerは昨年5月に最初のドラフトが公開されたばかりの新しいAPIですが、Webの前提を変える可能性を持った基盤APIとして注目されています。WorkerはあくまでWebの1つのAPIにすぎませんが、このミーティングではWebのこれからの方向性を考える上でも興味深い議論がいくつかなされました。ここで書かれる内容はあくまで議論された論点についてであって、本稿の内容が必ずしも将来仕様にのったり、実装されたりするわけではないことをご了承下さい。workers”のように表記が揺れて書かれることが多く、その正式名称をめぐってGitHub上でも議論があったほどです。worker”のように(つなげたり大文字にしたりせず)普通の英単語のように書くことで落ち着いたようです。Worker」と表記しています。WorkerについてはHTML5Experts.jpやHTML5Rocksなどで既にいろいろな解説記事が公開されているため、ここでは概要だけを紹介したいと思います。Workerの一種類で、Webページとは別にバックグラウンドで実行されるJavascript実行環境のひとつです。Workerとは異なり、一度インストールされるとブラウザ内に登録され、ネットワーク接続がなくても動作することができます。Webページのネットワークリクエストを横取りして任意のレスポンスを返すことができるという強力な特徴があり、Webページに対してオフライン機能やキャッシュによる高速化などを提供することができるのです。API[2]の仕様策定が一緒に進んでいます。Workerを拡張する形で従来のWebアプリではできなかったような機能を実現するためのAPIがいろいろ提案されています。APIを使ったプッシュ通知についてもいろいろな紹介記事が公開されていています。含めて安定版で動作しますので、興味のある方はぜひ試してみてください。Workerの仕様の一部として策定が進んでいます。Applicationsワーキンググループのワーキングドラフトとして公開されており、仕様に関する議論は(最近の流行りにのって)GitHubを中心に行われています。リポジトリはオープンなため、基本的には誰でも議論に参加することができます。いえ、議論が白熱しているときは一日に何度も更新されるため、すべての議論や変更をウォッチするのはなかなか大変かもしれません。Workerですが、判断が難しい問題や全体の方向性に関わる議論はそれだけではなかなか進みません。そのため、(多くのAPIやワーキンググループがしているように)ときどき関係者が実際に集まって顔をあわせて議論するためのF2Fミーティングが開かれています。Workerについて議論するカジュアルなF2Fミーティングが開かれました。Workerの次のフェーズについてなど、さまざまな議論が行われました。F2Fミーティングの議事録はこちらに公開されています。Kellyが自身のブログでミーティングのハイライトについて書いており、こちらも参考になります。Googleサンフランシスコオフィスの窓からの眺め。ベイブリッジがちょうど窓から見渡せる位置にあり、天気の良い日は良くも悪くも気が散ります。今回のF2Fミーティングでは、GitHubで日頃から議論に積極的に参加しているGoogle、Mozilla、Samsungからの参加者に加え、AppleやMicrosoftからも参加があり、活気のあるミーティングとなりました。2”という表現が出てきますが、要は「比較的要件がはっきりしていて現行の仕様にすぐ取り入れたいもの」と、「さらなる議論が必要そうで次フェーズまで待ちたいもの」という感じの位置付けになります。WorkerやWebの今後の方向性につながりそうなトピックをいくつか取り上げ、議論の背景と内容を簡単に説明してみたいと思います。3.Googleサンフランシスコオフィス:ものすごい余談ですが、MozillaのサンフランシスコオフィスはGoogleオフィスの隣のビルにあります。Worker内でレスポンスデータをキャッシュに格納したり置き換えたりする部分をJavascriptからプログラマブルに行えるようにするために考えられたAPIです。Worker外でも使えるようになりました。APIが実質HTTPからでも使えるようになることを意味します。すると、例えばHTTPページに埋め込まれたiframeでHTTPSページをロードし、HTTPSオリジンのCacheの中身を書き換えるようなことも技術的にはできるようになります。APIのストレージを汚染される可能性があるわけです。APIをHTTPSのみに制限するべきではないかという議論が起こりました。APIはHTTPで使えるべきではないという強い意見が出されています。一方で、開発者の立場に立った場合、HTTPSのみにすると開発が困難になるのではという意見も出されました。F2Fでは結局最終的な結論は出ませんでしたが、緩い制限から厳しい制限に後から移行するのはその逆に比べて難しいため、とりあえず実装が進んでいるブラウザではHTTPSのみに制限して様子を見るという暫定的な方向性が示されました。Chromeでもバージョン46からHTTPSのみに制限される予定です。Worker外ではそれほど使い道のないAPIなためマイナーな変更とも言えますが、今後のWebの方向性を見る上では考えさせられる議論です。Workerの次フェーズとも言える仕様として、navigator.connectというAPIが提案されています。Worker間で通信をするための仕様で、navigator.connectのGitHubでは「ページ(document)がなくても動くiframe間のpostMessageのようなもの」と説明されています。複数オリジンのサービスをつないでマッシュアップするためのRPCのような仕組みと言い換えることもできます。非公式の仕様ドラフトでは、ユースケースとして「オフライン・アナリティクス」や「クラウド・ストレージ・プラットフォーム」などの例が挙げられています。Analyticsをはじめとする多くのアナリティクスはRESTインタフェースを提供しており、オフラインでは当然動きません。Workerと通信するしかありません。Workerと通信できるようになります。Workerと通信してさまざまなサービスを受けることが簡単にできるようになる(かも知れない)のです。このように大変強力な提案ですが、議論がまだ詰まってないところが多く、仕様化もこれからの段階です。Fetchという対案を出しています。Workerを連鎖させることも可能になります。2に先延ばしされることになりました。事前にミーティングで議論したい点のリストが共有されました。可能性を議論するものになっています。Workerは、本稿の概要でも軽く述べたとおり、そもそもWebページのネットワークリクエストを横取りして動作することを念頭に置いて設計されたAPIです。Workerにとっては不要な」部分も組み込まれていることになります。Workerはすぐに使えるようにはなりません。Workerが足元で置き換わることがないように設計されているためです。Workerを使ってる場合、この制限は不便なだけであまり意味がありません。Workerにもダミーのスコープを割り当てないといけません。1の仕様に反映されることはなさそうですが、次フェーズに向けて今後さらに議論されていくと予想されます。Workerが議論されるようになってきたことは興味深いことです。終わりにF2Fミーティングでは他にも興味深いさまざまなトピックが議論されました。Workerありの世界でどのように再定義するかに大きな焦点があったように思います。Workerに焦点が移りつつあるのかもしれません。Meetings)中にやろうという提案がされています。Meetupもあります。