スライド

XULの役割＝ユーザーインターフェース

アプリケーション開発のための言語……ということでXULをご紹介していますが、DHTMLとの比較からお分かり頂けるかも知れませんがXULだけではアプリケーションは作れません。XULはあくまでHTMLと同様に「ユーザーが触れる部分」を設計するためだけの言語です。

DHTMLではこれをアプリケーションとして動作させるためにJScriptやVBScriptを使います。XULアプリケーションでは、この部分をJavaScript（あるいはPython）が担当することになります。また、JavaScriptで補いきれない機能、例えばファイルの入出力や高度な通信機能などについては、DHTMLやHTMLアプリケーションだとWindowsのActiveXに任せることになりますが、XULアプリケーションではここでXPCOMというAPIを使うことになります。ActiveXがWindows用の技術であるのに対して、XPCOMは「Cross Platform Component Object Model」という名前が示すとおり、Windows、Mac OS、Linuxといったいくつものプラットフォームで全く同じように機能するのが特徴です。

質疑応答

小セッションではこの点について、「ActiveXはよくセキュリティホールの温床として名前が挙がるが、XPCOMでもそういうことが起こるのではないか？」「通信機能とあるが、HTTPやFTP以外のプロトコル、例えばSSTPなどは使えるのか？」「ガイドラインに沿ってXPCOMの機能を新たに自分で作った場合、それは自動的に他のプラットフォームでも実行できるようになるのか？」というご質問を頂きました。これについて補足説明を加えておきます。

XPCOMのセキュリティについて

まず、セキュリティホールの問題についてですが。ActiveXの機能は、IEの設定次第ではWeb上に置かれたコードからも確認なしで呼び出すことができます（詳しくは知らないのですが、インターネットオプション→セキュリティ→レベルのカスタマイズにそのような項目があるので、そう判断しました。誤解してたらすみません）。それに対して、XPCOMは「クライアント側にインストールされたXULアプリケーション」でなければ絶対に呼び出せないというセキュリティ上の制限がかけられています。もちろん、バッファオーバーランなどのセキュリティホールを突かれる可能性がないとは言い切れませんが、少なくとも仕様上は、Web上に置かれた悪意あるコードを知らない間に実行されるということはありません。

他のプロトコルのサポートについて

次に、SSTPについて。Mozillaの現在のコードではSSTPには対応していませんが、SSTPの仕様はHTTPによく似ているようなので、対応させること自体はそう難しくないと思われます。ただ、クロスプラットフォームな「伺か」を開発するとなると、透明部分を含む画像をそのままデスクトップ上に表示する機能が必要になりますが、残念ながらXULでは「ウィンドウ」という枠の中に表示することまでしかできませんので、見た目的にはネイティブアプリケーションの「伺か」と全く同一のものを作るというわけにはいきません。

XPCOMコンポーネントの開発

最後に、自作のXPCOMコンポーネントのことについて。これにはKENZ氏からご説明を頂きました。

XPCOMの各コンポーネントは、「JavaScriptから呼び出す際のインターフェースがプラットフォームに依存しないように統一されている」というだけで、バックエンドではあくまで各プラットフォーム向けに別々にビルドされたバイナリ、例えばXPCOM for Win32やXPCOM for Macといった感じのものが実行されています。つまり、Windows上で開発したXPCOMコンポーネントをバイナリレベルでそのままLinuxに持ち込んで使うといったことは残念ながら不可能です。

ただ、MozillaのXPCOMの開発においては、可能な限り同一のコードで複数環境に対応するための工夫が随所に凝らされています。それらのコーディング上のテクニックを参考にして頂くと、クロスプラットフォームなXPCOMコンポーネントの開発もしやすくなるのではないでしょうか。