mozIRegistry

はじめに

このドキュメントのタイトルは、とても誤解を受けやすいものになっています。実は、「レジストリインタフェース」についてのドキュメントではありません。このドキュメントは、インタフェースのクライアントとインタフェースの実装を実際に提供するコードとの間の、よりダイナミックな結合を Mozilla がどのように支援しているか、ということについて述べています。

この目的のため、ソースコードの中の明確なある場所において (実際には) どの実装が使われるか、という情報の保存が必要になります。 そして、今までのところ、我々はその情報を「Netscape レジストリ」ファイルに格納することにしています。 以上が、この (ドキュメントの) 情報が「レジストリ」という概念とどのように関係するようになるのかということの説明です。

いつか (私の希望ですが) このページのタイトルが適切に付けられるはずです。そうすれば、この場所が、Mozilla ブラウザを形成する様々な XPCOM コンポーネントがどのように互いに結びつくように考えられているか、を発見するための場所であることを皆さんが理解できるようになるでしょう。以下の情報は、それがどのように行われるかについて、あなたが知るべきすべてのことを説明するためのものです。

要約

クライアントは、任意のクラスのインスタンスを作成するために、nsRepository に依存します。 CLSID のダイナミックな結合を必要とするクライアントは、使用する CLSID を解決するために、ある高水準のサービス (TBD) を使う必要があります。 そのようにする意図は、そのようなサービス自身が新しい mozIRegistry インタフェースの上層部に作られるからです。

我々は、新しい XPCOM インタフェース「mozIRegistry」を提案します。これは、libreg で実装されていた「Netscape レジストリ」の機能と同じレベルの機能を提供します。nsRepository は、このインタフェースを使用するように修正されるでしょう。それによって、別のレジストリの実装を実行時/リンク時に置き換えることができるようになります。2 つのレジストリインタフェースの実装が存在するでしょう。ひとつは、libreg だけに基づいたもの (互換性のため) で、もうひとつはより装飾的な RDF ベースのものです。

未解決の問題

我々は、2 つの未解決な問題を認識しています。どちらもタイムリーに解決できないほど、大変なようには見えません。

1. もし現在の CLSID の静的な結合を取り除いた時は、要求された CLSID が存在しないリスクがあるかもしれません。 必然的結果として、新しいクラス実装へアクセスできるように、ビルド/インストールプロセスがユーザ「レジストリ」の更新をしなければならないでしょう。 我々の現在のビルド/インストールプロセスは、まだそれらの問題を解決していません。
2. 起動時において、mozIRegistry インタフェースにアクセスするためのサービスマネージャの使用に関係する問題がいくつかあります。現在のところ、nsIServiceManager は、そのサービスの実装をハードコードしているサービスにアクセスするために CLSID を必要とします。この問題は、別の mozIRegistry の実装を可能にするために、または実行時に結合される他のサービスマネージャの実装を可能にするためにも解決されなければなりません。私は、単純な CLSID の「別名」の仕組み (ある意味で COM の「コンポーネントカテゴリ」と同等の仕組み)、およびサービスを「設定する」ことができるようにする (これは、サービスマネージャがサービス自身を作成するというのと対立します) ことで、解決できると思います。最悪の場合は、クライアントは mozIRegistry シングルトンを他の手段 (つまり「NSGetRegistry」関数) を通じて取得するかもしれません。

アーキテクチャ

この図は、他の Mozilla コンポーネントと相互作用するために使われる、様々なコンポーネントを示しています。

いくつかは、説明のためのものです (図の上部付近の明るい色の箱)。これらには、(実際に) あなたが設計し、かつ実装するコンポーネントの型が入ります。 私は、それらについて説明して、あなたが他の箱をどのように使うべきかということの例を示そうと思います。

暗い色の箱で示されるコンポーネントは、あなたが使うサービスです。 このドキュメントで、これらのコンポーネントの設計と実装の原則について説明します。

最後に、(「mozRDFRegistry/nsIRDFDatabase」というラベルが付いている) ひとつのコンポーネントがあります。このコンポーネントは、mozIRegistry インタフェースのひとつの改良された実装として明らかになるかもしれません。 私は、その実装についてほんの短く論じる予定です。(その主な理由は、その実装を誰かにやって欲しいからです。)

高水準のアプリケーションコンポーネント

この箱は、潜在的ユーザのコアのレジストリ/リポジトリインタフェースを表しています。

あなたのコードは、(たぶん) この箱に収まるでしょう。

これらのコンポーネントは、その任務を果たすために、様々な度合で、他のコンポーネントを使う必要があるでしょう。これらの他のコンポーネントは、おそらく特定の XPCOM インタフェースを実装します。 あなたのコンポーネントが必要とするインタフェースを実装するオブジェクトを生成するにはどうすればよいでしょうか。

ひとつの方法は、nsRepository を使ってインタフェースを生成することです。 nsRepository は、元々 XPCOM の CLSID からクラスファクトリーへのマッピングであり、加えてそのマッピングを管理し、与えられた CLSID のインスタンスを生成する関数を含むものです。

nsRepository 関数は、nsRepository.h で宣言されています。 nsRepository についてのもっと多くの情報は、下 にあります。

他のコンポーネントにアクセスする 2 つ目の方法は、サービスマネージャを経由することです。これについては、このドキュメントではカバーされません。上の注 を見てください。

このセクションでは、多くの異なるコンポーネント、それらの他のコンポーネントへのダイナミックな結合の要求、そしてそれらがその要求を満たすためにどのようにコア XPCOM コンポーネントを利用するか、について論じるつもりです。

• i18n
• XUL/xpToolkit
• App Shell

CLSID 結合プロトコル

ここには、レジストリーへの CLSID 情報の保存と、nsRepository を使った、コア XPCOM サービスの上層部でのインスタンス作成プロトコルを実装するための、その情報の使用の特定のイディオムの潜在的なカプセル化について書く予定です。

これらは、提供している基本的なサービスによって、2 つのカテゴリーに分かれると思います。

• 与えられたインタフェースの実装を見付ける。
• 与えられた任意のプロパティに適合する適切な実装を見付ける。

nsRepository

これは、基本的に今提供されているものと同じです (mozilla/xpcom/public/nsRepository.h を参照してください)。 このコンポーネントに対する主な変更は、今まで呼んでいた NSReg.h の関数ではなく、新しい mozIRegistry インタフェースを利用するようにしたことです。 加えて、あまり重要ではない、いくつかの拡張があります。

• Initialize() で .reg ファイル名の指定をサポートしている。

このことは、(今よりは) もう少し柔軟性を増すことにつながり、その結果、XPCOM をより汎用的にすることができるでしょう。

• 初期化担当者 (クライアントアプリケーション) が、基本的な mozIRegistry の実装を仕立てることができるようになった。

そのため、より進んだ実装 (例えば RDF ベースのもの) と基本的な libreg ベースのレジストリーの実装との間で選択することができます。

nsRepository は CLSID だけを知っています。クライアントコンポーネント/アプリケーションは CLSID を取得する責任があります。 このテーマは、いくつかの点でもう少し説明が必要です。 基本的に、それらのサービスが mozIRegistry インタフェースに基づくべきだと想像します。 言い替えると、Rick が先週示唆したように、それらはレジストリーとリポジトリーの上層部にプロトコルを実装するでしょう。

mozIRegistry

これは、新しいインタフェースで、現在 mozilla/modules/libreg/include/NSReg.h で定義されている libreg (「Netscapeレジストリー」としても知られている) が提供しているのと基本的に同じ関数を外に見せるものです。 クライアントは、このインタフェースをサービスマネージャを通じて、取得します (mozilla/xpcom/public/nsIServiceManager.h を見てください)。

mozRegistry

これは、とても簡単な mozIRegistry インタフェースの実装です。 NSReg.h の関数のための単純な C++ ラッパーとして作られています。 これは、現在の libreg の使用と完全に互換性のある (もう少し) 軽い実装を提供することを意図しています。

mozRDFRegistry

これは、付加的な能力を提供する RDF ベースの mozIRegistry 実装です。 これらの付加的な能力は、nsRepository によっては利用されないことに注意してください。 libreg の .reg ファイル、共有ライブラリのインストール、net を通じてアクセス可能な追加のコンポーネント、などに対応する基本的な RDF データソースの複数のタイプがあるでしょう。

この RDF データベースのコンテンツは、プレーンテキストの rdf/xml ファイルとして保存されます。そのため、中を見たり編集したりするのが簡単にできます。 またそれにより、人々が表示したりそのコンテンツを編集したりできるような、ブラウザーベースのアプリケーションの構築が容易になります。