2005-07-16

ある派閥争いの話 補遺

以前 ある派閥争いの話 について書いた. その変奏を思いだしたので書いておく.

HTML を表示できるアプリケーションを書こうとしたことがある. その時 IE コンポーネント (IWebBrowser) を使うかわりに Mozilla の Gecko エンジンを使おうと調べた. 信仰上の理由からだ. build をして動くところまでは辿りついたものの, 調べていくうちにこれを使ってアプリケーションを書く気が失せた. 私の目的からすると Gecko の作りは都合が悪い. IWebBrowser2 や Webkit の方がずっと良さそうだ.

IE や Safari は, IWebBrowser や Webkit という HTML 表示機能をもつライブラリの API を利用し, そのライブラリが提供しないメニューやツールバーなどの GUI 部分を独自に作っている. (はずだ. 非公開 API を使うといった裏口があるとは思うが基本的にはそうだろう. Slepnir など, サードパーティのブラウザは確実にそう作られている. 他に方法がないからだ.) ここでは, HTML 表示機能を提供するライブラリとそれを利用するアプリケーションという責任分担がはっきりしている. ライブラリの責任範囲は API によってはっきり定義されている.

Mozilla や Firefox は異なるアプローチをとっている. これらのアプリケーションは Gecko というアプリケーション・フレームワークを用いて構築されたアプリケーションである. Gecko は HTML 表示機能だけでなく, XUL という GUI 構築のための枠組みをもっている. XUL は GUI を記述するための XML で, Gecko は HTML の他にこの XUL も解釈して表示できる. Mozilla/Firefox は XUL を用いて GUI を構築している. いってみれば Gecko にとって Mozilla/Firefox の GUI はウェブページのようなコンテンツの一種に過ぎない. そして, Mozilla/Firefox のアプリケーションとしてのコードはほとんど XUL と JavaScript だけからなる. それ以外の(C/C++で書かれた)コードは Gecko の一部になってしまうからだ. Gecko のソースツリーは, Firefox/Mozilla 固有のコードというのをほとんど区別しない. つまり Gecko はフレームワークであり, 加えてホットスポットとの責任分担が明確でないホワイトボックス・フレームワークである. どのオブジェクトのどのメソッドががアプリケーションのための API なのかがはっきりしない.

Gecko の HTML 表示機能を自分の作っているアプリケーションの一部として使おうとすると, このアプローチは都合が悪い. Gecko を使ったアプリケーションは Gecko の流儀 (XUL 主体の GUI 構築) で動く必要がある. アプリケーション開発者の慣れ親しんだツールキット (MFC, WTL, VCL, GTK+, etc) の上で動かすのは難しい. 既存のアプリケーションから利用するのも同様の理由で困難だ. MFC の CWnd を VCL で作ったアプリケーションの中で使う(あるいはその逆)を想像するとわかりやすいかもしれない. 加えて API のスコープが曖昧だ. うっかり内部のモジュールを使ってしまい, ある日バージョンを変えたらその自分の使っていた API がなくなっているかもしれない.

Mozilla 開発者もそうした問題を 認識しているのだろう. Mozilla のソースツリーには, Gecko をライブラリとして使うための "embedding" というモジュールが含まれている. embedding モジュールは Gecko のフレームワークを外側から呼びだすよう実装されていて, これを使えば確かに IE コンポーネントと似たようなことができる. 問題は, この embedding モジュールが Mozilla/Firefox など Mozilla 財団製 suite の開発に使われていない点にある. 主流のアプリケーションから使われていないため, embedding モジュールの開発は盛んでない. たとえば embedding を使ったブラウザの開発者が Firefox の新機能を真似したいと思った時には, Firefox 開発者が Gecko に対して行った改造を確認し, それを真似しなければならない. Firefox 開発者はサードパーティーのブラウザに気を使ってはくれない.

Gecko の API の一部は "freeze" 宣言によって変更を禁止されるものもある. しかしそれらは Gecko のフレームワークから利用する種類の API に対して行なわれるもので, フレームワークの外側への配慮は薄い. コードはある日がらりと書換えられるかもしれない.

そんなわけで embedding モジュールを使ったサードパーティ・ブラウザの開発は気が進まない. 加えて, embedding モジュールは Gecko の内部を完全に隠蔽してくれるわけではない. Gecko embedding を利用するためには Mozilla のビルドシステムに自分のアプリケーションを組込む必要がある. ヘッダファイルは Gecko のコンポーネント群に依存しているし, プリプロセサのシンボルやコンパイルオプションは文書化されていないからだ.

要するに Gecko は閉じたフレームワークで, それを "外側から" 利用するのはとても面倒で難しい. この面倒くささは生半可な信仰心で乗り越えられるものではなかった. (もちろん強い意志があれば克服は可能である.) ちなみに Slepnir の Gecko サポート は IWebBrowser 互換の API (これも非公式なもの)によって実現されている. ものかなしい.

少しは希望もある. LibXUL はこうした問題を解決しようという試みらしい. これを利用したアプリケーションが Mozilla 財団によって開発されるなら, 事態は改善するだろう. 逆に主要なアプリケーションがLibXUL を利用しないなら, embedding と同じメンテナンスの問題を抱えることになるだろうし, 人々は相変らず IWebBrowser を使うだろう. 結局これもまた, フレームワークとライブラリの間におきた派閥争いの一幕なのだ.

できるものなら Gecko を使いたいのだけれどなあ. 信心深いんだ. 私は.