{{ Outdated("このページは 2001 年 8 月を最後に更新されておらず、歴史的重要性を残すにとどまるでしょう。") }}
完了
XPCOM のもっとも重要な目標は、何年も前から述べられているとおり、ブラウザを船出させることでした。そこまでこぎつけました。そして今、私たちは複数のバージョンの Mozilla ブラウザを得ています。 Netscape 6.x、Galleon、など。最近数週間を通して、次に何をすべきかについて XPCOM を使っているさまざまなグループと意見交換をしました。使用者たちは API セットの変更に追従するための労力を費やしたくない、というひとつのことが、くっきりと明瞭になりました。これらの議論から、私たちは Mozilla 1.0 リリースへの迅速なアプローチとして、要求される XPCOM インタフェースに対して 最小主義的なアプローチをすべきだと信じます (例：どうしても必要な最小限の API だけをフリーズ (固定) する)。
安定した API を危機的なほど必要としている二つの利用者は、プラグインと組み込みです。いずれも XPCOM の初期化、停止、コンポーネントとサービスの管理を可能とする XPCOM の API のセットに興味を持っています。 Mozilla 1.0 のためには、XPCOM は最低限としてこの機能性を得られる API をフリーズすべきと信じています。
私たちは組み込みグループで作業してきています。そして 必要と考えられるインタフェースのこのリストを提示しました。(これらのインタフェースのいくつかは XPCOM には当てはまらないことに注意) もし、必要と思われるのにこのリストから抜け落ちている XPCOM インタフェースが見つかったら、私 Doug Turner 宛にメールをするか、XPCOM ニュースグループ に投稿するかをぜひお願いします。
もっとも重要な目標は XPCOM 中核の機能へのインタフェースのフリーズです。
私たちのリスト上の現在のインタフェースリストは、基本的な COM の機能を含んでいます。スレッド処理、リフレクション、多くのデータ構造など、ほとんどの XPCOM の機能は Mozilla 1.0 を前にしたこの時間枠において、フリーズされないでしょう。
この SDK はインタフェースのセットと接続ライブラリをフリーズすることも含むでしょう。このインタフェースのセットは、組み込みとプラグインの要求によって定義されてきました。これらのインタフェースは以下のものを含んでいます:
接続ライブラリは、気軽に使えるクラスとマクロのセット、そしてフリーズされていないクラスで構成されます。これをコンポーネント開発者は、例えば XPCOM にリンクしなくてよい nsCOMPtr の構成要素を活用することができます。次に重要な目標は XPCOM 中核の機能へのインタフェースのフリーズです。
ひとたび、フリーズされたインタフェースのセットを得ました。これらのインタフェースの実装の内部の起動・終了・スレッド処理などの問題に言及しなくてはいけません。トラッキングバグ {{ Bug(101976) }} の追跡で言及されるべき知られた問題を一覧とすることができます。
XPCOM 改良のための全体的な計画は、小さくすること、シンプルにすること、クリーンにすること、必要な機能によりチューニングすること、より関係する標準に沿わせること、などを中心に展開しています。 XPCOM を軽く保つほど、XPCOM のデバッグ、移植、保守が楽になり、アプリケーションの組み込みの手間が減ります。そのためには、それほどには活用されない XPCOM の機能はもう必要ないでしょう。単独のクライアントが使うためだけに存在するものは、検証済みでなくてはならず、願わくば根絶されるべきです。
XPCOM の機能の大きな部分が、C++ クライアントへ向けられています。標準 C++ ライブラリを使った組み込みアプリケーションを期待することができます。 XPCOM の機能が標準 C++ ライブラリによって提供される類似のサービスと重なっている場所では、 API と機能を標準ライブラリのそれへ変換したいです。いずれは、クライアントは標準ライブラリから実装を入手できるようになり、API が取り除かれるようになります。
標準ライブラリから提供されるのではないこれらの機能のために、私たちは適切に標準ライブラリと互換を持った API を作りたいのです。例えば、XPCOM の container は標準アルゴリズムとともに働くべきでしょう。