つい先日更新された Mozilla の新しい Roadmap 絡みで、XUL のアプリケーションフレームワークの構成がだいぶ変わりそうなのだけど、ちょっとぼくはこんがらがってる。ちょっと自分で思いつく範囲で整理を試みてみる。
元々、Mozilla Seamonkey は、xpfe 上に構成されたアプリケーションであり・・・というか Mozilla Seamonkey の下にアプリケーションを実行するためのツールキットである xpfe が用意されていた。相互に不可分であり、フレームワークとしての xpfe の価値はあくまでポテンシャルレベルだったのかも知れない。そういえば、Komodo は Mozilla と同じフレームワーク上に別のアプリケーションを構築するために、Mozilla (0.9.5) そのものをアプリケーションの一部に内包していた。
Phoenix が立ち上がった頃か、その後すぐくらいに GRE と（たしか）同じタイミングで XRE という形で、単体の XUL アプリケーションを作れるようなランタイムを提供するというプロジェクトが立ち上がっていて、どちらかというとこれは XPFE の分離と再構成を目指してるものだったと思う。イメージ的には、XRE 単体では人が使えるアプリケーションとして成り立たないが、これの上に、これ以外との依存性の無いアプリケーションを作ることが出来るひとつのフレームワーク的なものと認識している。
ひとまず新しいロードマップでは、 Phoenix が新しいツールキットだ。たぶん、少なくとも当分の間はそれぞれのコンポーネントがある程度差別化できるツールキットを保持し、それらをフレームワークとして利用する Extention を作成することが可能で、それぞれのツールキットは Mozilla Suite よりも小さくシンプルな XUL 実行環境となる。但し、少なくとも当分の間は、Phoenix Toolkit が必要だ。
これは至極短期的に起こりうる状況を予想した上で持った印象ではあるが、Phoenix をツールキットとして利用するよりも、Seamonkey の土台である xpfe を独立したアプリケーション・フレームワークとして分離した方が実用的な段階に到達するまでに時間が掛からないんじゃないかという気がする。
例えば、OEOne はそのまま今の Phoenix Toolkit に移行することは出来ないだろう。Window Manager レベルのアプリケーションを構成するのには構成要素が足りないからだ。いや、これはぼくの勝手な想像で、既にそれは可能なのかも知れない。でも、仮にそうだとした場合、未だにあまり無いがそういったある程度大きいアプリケーションを作るには (少なくとも短期的には) xpfe 以上に embedd しづらいものになり兼ねないんじゃないだろうか。
違う見方もできる。1.4 branch が最後の xpfe 系プロダクトになるため、これが 1.0 で期待されていたような形で利用されるような、ある意味逆行的な動きも見受けられるようになるかも知れない。
新しい仕組みは XUL に汎用性を与えることに成功するのか？それは分からないが、恐らく最低 2 段階の re-organization が必要であり手早くガラリと変わることができるものではないことは確かだと思う。
追記 (mozillaZine のコメントより)。
XPFE is actually a bunch of stuff that’s been thrown together. It is A. the current toolkit for the Mozilla suite, and B. portions of the browser UI. What phoenix has done is fork some of these files, and made the lines clearer between what is part of the toolkit, and what is just the front end UI. Everything is still XUL/JS/CSS, it’s just different XUL/JS/CSS in places, with a lot of the bloat removed. Phoenix uses mozilla/browser for it’s front end, and mozilla/toolkit for it’s toolkit. Minotaur uses mozilla/mail for it’s front end, and mozilla/toolkit for it’s toolkit
Leave a Reply