Latest topics > Google Chrome Extensions

Google Chrome Extensions - Dec 16, 2009

GoogleChromeの拡張を作る上でFirefoxアドオン作者が知っておくべきやればできること « kuでFirefoxアドオンの自由度は奇跡的です。millennium | Google Chrome Extensionsを読んでその奇跡を噛み締めましょう。と紹介されていたエントリを勝手に翻訳してみました。原文の著者は、Firefoxの初期開発チームの一員で、今はGoogleに転職してGoogle Chrome開発チームの一員となっているBen Goodger氏です。

---

Chromeチームは今日（※訳注：2009年12月8日）、Mac OS XとLinux、そして拡張機能に対応した最初のバージョンをリリースしました。これは、非常に多くの人達の1年間にわたる作業の完成を意味しており、私は開発チームがこの目標を達成できたことを誇らしく思っています。そこで、拡張機能について少し語る機会を設けることにしました。

Chrome拡張機能APIはユーザと開発者に対して、Chromeの核となる原則である「速度」「安定性」「安全性」そして「シンプルさ」を保ちながらブラウザをカスタマイズする能力を提供します。

Google Chromeの拡張機能には以下のようなことができます。

• JavaScript、HTML、CSSなどの一般的なWeb技術によって簡単に開発できます。
• それぞれ別々のプロセスで実行されるため、ブラウザ全体の動作を遅くさせるような問題は起こりません。
• 限定的なAPIを持っており、各拡張機能はブラウザのタブと同様のサンドボックス内で実行されます。
• Chrome自身と同様の自動アップデートの仕組みを使うため、開発者は彼らのソフトウェアの新しいバージョンを容易に公開することができ、ユーザは何もしなくても、最新・最高・最も安全なバージョンにアップデートし続けることができます。

Google Chrome拡張機能についての動画はここで見られます。

私はここしばらくの間、ブラウザの開発に関わり続けてきました。私の話を興味深く思う人もいるでしょうから、拡張機能の歴史について少しお話ししましょう……

かつてNetscapeがNetscape 6（ブラウザ、メールクライアント、ページ作成ツール、そしてIMクライアントのセット）を開発していた頃の要求仕様の1つとして、メールクライアント、IMクライアント、ページ作成ツールといった「選択式の」コンポーネントを含めずにブラウザだけをインストールできるようにする、というものがありました。それらのコンポーネントをインストールした場合は、メールクライアントやIMクライアント等を起動できるようにするために、ブラウザのUIに「追加の項目（メニュー項目、ツールバー上のボタンなど）」が表示されることになります。

NetscapeのフロントエンドはクロスプラットフォームなUI言語であるXULによって実装されていました。選択式のコンポーネントは、それらがインストールされている場合に「追加の項目」を加えられるよう、「オーバーレイ」と呼ばれるファイルを含んでいました。選択式のコンポーネントはそれ自身のオーバーレイや他のロジックを「XPI」ファイルの中にパッケージングされていて、インストールエンジンによってインストールされるようになっていました。

何年か後、Netscapeの後継者であるFirefoxの人気が高まると同時に、開発者達は、前述のようなコンポーネントのインストールのための仕組みを、ブラウザに対して他の機能を追加するためにも利用できるという事に気がつきました。この機能自体はNetscapeの自社製品以外が使うことを全く想定せずに作られていたので、ブラウザのUIの中でどんなAPIが公開される必要があるのかといったことに対しては十分な注意が払われていませんでした。本当に単なる内部的なAPIでしかなかったのです。そのため、人々がFirefox用の「拡張機能」の開発を始めたばかりの頃は、Firefoxに何か変更が行われるとその度に拡張機能のせいでブラウザが起動しなくなるというのが日常茶飯事でした。Firefoxの初期の頃には、ある拡張機能（※訳注：多分タブブラウザ拡張のことじゃないだろうか。というのは自意識過剰？）をインストールしていたユーザにとっては、Firefoxの新しいバージョンにアップグレードする度に「ブラウザにXBLのバインディングが適用されていません」というエラーにぶつかる、といったことも珍しくありませんでした。

Firefoxがバージョン1.0に達する前にこの問題を解決しなければならないのは明らかでしたので、私は拡張機能マネージャをFirefoxに加えることにしました。これは、インストールやアンインストールのためのやっかいなコードを書かなくても済むようにすると同時に、より重要な点として、バージョン管理のための仕組みを提供するものでした。安定したAPIが無い以上、システムは単純に、ブラウザのそのバージョンに対して互換性があると明記されていない拡張機能を無効化します。これは開発者達にとって、新しいバージョンのFirefoxがリリースされるごとに毎回、彼らの拡張機能の動作を保証しなければならないということを意味します。この仕組みは完璧でもないし、煩わしいものでしたが、しかしそれなりにうまくいったため、私達はひとそろいのAPIを凍結させなくてもよかったのです。APIの凍結を急かされていたら、まず間違いなくそれはおざなりな物になってしまっていたでしょう。

Firefoxの拡張機能は常に諸刃の剣です――それは計り知れない柔軟性を提供しますが、その引き替えに、ブラウザがアップデートされるごとに毎回動作確認を取らなければいけないというコストを開発者に対して強います。開発者の動作確認が遅れた場合、ブラウザの新バージョンがでてすぐにアップグレードしたユーザは、しばらくその拡張期能なしで過ごさなければならないか、あるいは、互換性の確認の過程を自己責任で無効化する必要があります。

私はこの歴史についての覚え書きには、面白いというだけでなくケーススタディとしても価値があると考えています。もし、Netscapeのコンポーネント式のインストールのおかげでこのブラウザのカスタマイズのための「裏口」が存在していなかったら、Firefoxに拡張機能の存在自体が全く無かったかもしれないのです。考えてみて下さい。その機能がユーザに愛されたために、Firefoxは成功したのです。これは驚異的な事です。この前例があって、ユーザが拡張機能を愛しているということが分かったので、私達Google Chromeチームは今、カスタマイズ性とChromeの核となる原則とを両立させる最良の物を作るべく、新しいAPIをゼロから作るという贅沢が許されているのです。

Firefoxでの体験は計り知れないほど有益な物でした。私は、Google Chromeの拡張機能の開発に個人的に寄与した数多くの技術者達のうちの1人ではありませんが、しかし、機能をどのように実現するかを検討する事については十分な戦歴があります。私はChrome拡張機能のチームがこのアプローチを取ることを決定した事をとても嬉しく思います。最初のマイルストーンへと私達を導いてくれた彼らに賞賛を！