プラグインの作成
一度プラグインにさせたいことを決めたら、それを作成することは単純な工程です。 基本的なプラグイン開発概観は以下の手続きで与えられます。
- プラグインを計画します: プラグインソフトウェアに提供させたいサービスやブラウザとの相互作用のさせ方やプラグインが作成する特別なメディアを決めます。
- プラグインに対する MIME タイプやファイルの拡張子を決めます（プラグインの登録を参照してください）。
- 開発環境を適切に設定してください。プラグインを作成するための多様な開発環境を使えます。しかし mozilla のソースやプラグイン SDK から必要なファイルを持ってくるようにしてください。
- プラグインプロジェクトを作成してください。
既にビルドされているプラグインソフトウェアのある、mozilla ソースディレクトリ内のあなたのオペレーティングシステムに対して提供されているサンプルの一つから始めるか、SDK の提供するファイルを使用して開発環境内で新しいプラグインプロジェクトを構築するかできます。SDK の使用やそこで提供されているサンプルの使用についての情報に関してはプラグイン SDK 内の README を参照してください。 - プラグインのコードを書いて基本的なプラグイン操作に対するプラグイン API メソッドを実装してください。プラグイン API のすべての主要な機能領域に対する分割された章と同様にこの章の中でプラグイン API メソッドの概観が見つかるでしょう。ブラウザからプラグインをアクセスできるようにすることについて更なる情報に関してはプラグインのスクリプト化可能化を参照してください。
- あなたのオペレーティングシステム用のプラグインをビルドしてください。「プラグインのビルド」を参照してください。
- あなたのオペレーティングシステム用のプラグインディレクトリにプラグインをインストールしてください。プラグインのインストールを参照してください。
- 必要なときにプラグインをテストしデバックしてください。
- HTML ページを作成してプラグインのオブジェクトを組み込んでください。使用する HTML 要素についての情報に関しては、プラグイン表示のための HTML の使用を参照してください。プラグインが動作しているのを見るために、プラウザ内でそれを呼ぶ単純な HTML ページを表示してください。
プラグインの登録
Gecko はサポートする MIME タイプによってプラグインを識別します。特定の MIME タイプのデータを表示する必要があれば、ブラウザはそのタイプをサポートするプラグインのオブジェクトを見つけて起動します。データは HTML ファイルの object 要素（ここで object や embed 要素は MIME タイプを直接指定するかそのタイプのファイルを参照します）やその MIME タイプの分割された非 HTML ファイルやサーバーに由来します。
サーバーはファイルの拡張子をもとにプラグインによって登録された MIME タイプを探し、ブラウザにファイルを送り始めます。ブラウザはメディアタイプを調べて、そのタイプに登録されたプラグインが見つかったならば、そのプラグインソフトウェアを読み込みます。
起動するとき、ブラウザはプラットフォーム用のプラグインディレクトリ内にプラグインモジュールが無いか調べてそれらを登録します。ブラウザはプラウザにとってプライベートなユーザ設定とプラグインディレクトリの内容を組み合わせることを通じて、どのプラグインがインストールされ、どのタイプをプラグインはサポートするのかを決めます。
MIME タイプは（アプリケーションや画像のような）メジャーなタイプとマイナーなタイプから構成され、例えば image/jpeg のようになります。プラグイン用の新しい MIME タイプを定義したならば、IETF (Internet Engineering Task Force) でそれを登録しなければなりません。新しいUntil your new MIME タイプが登録されるまでは、名前に接頭語 "x-" を付けて、例えば image/x-nwim のようにしてください。MIME タイプについての更なる情報に関しては、以下の MIME RFC を参照してください:
- RFC-1521: "MIME: Mechanisms for Specifying and Describing the Forms of Internet Message Bodies"
- RFC-1590: "Media Type Registration Procedure."
異なるプラットフォーム上でのプラグインの扱い方にはいくつかのバリエーションがあります。以下のセクションはプラットフォーム固有の発見と登録を説明しています:
MS Windows
Windows 上ではブラウザアプリケーションと同じディレクトリ内にプラグインがあります。典型的なインストールではプラグインディレクトリはここにあります:
C:\Program Files\Mozilla Firefox\Plugins
レジストリを通してこのディレクトリを見つけることもできます。ブラウザはサブディレクトリを検索しません。プラグインは NP で始まり .DLL で終わる 8.3 ファイル名が付けられていなければなりません。
プラグイン DLL に対する Windows バージョン情報は MIME タイプ、ファイルの拡張子、ファイルオープンテンプレート、プラグイン名と説明を決めます。MIME タイプとファイルの拡張子の文字列では、複数のタイプと拡張子は "|" 文字で区切られています。例えば:
video/quicktime|audio/aiff|image/jpeg
ブラウザにプラグインを認識させるようにするには、プラグイン DLL のバージョンスタンプに以下の行が含まれていなければなりません:
- File Extents: for file extensions
- MIME Type: for MIME types
- Language: for language in use
開発環境で、言語が "US English" に設定され文字セットが "Windows Multilingual." に設定されているようにしてください。この言語と文字セットに対するリソースコードは 040904E4 です。
Unix
Unix では、プラグインはセクション どのように Gecko はプラグインを見つけるのか に従って見つけられます。プラグイン内でブラウザが呼ぶ関数は NPP で始まる一方でエクスポートされた関数は NP で始まることに注意してください。
プラグインが扱う MIME タイプやファイルの拡張子を決めるために、ブラウザは個々のライブラリを読み込んで エントリポイントへ呼びます。このエクスポートされた C 関数はセミコロンで区切られたタイプ、拡張子リストやタイプの説明を返すはずです。例えば: image/xbm;xbm;X Bitmap です。この情報はその結果 "about:plugins" にある JavaScript のオブジェクトの navigator.mimetypes 配列に現れるでしょう。
about:plugins にある JavaScript のオブジェクトの navigator.plugins 配列に現れるプラグインの名前と説明を取り出すために初期化中に NP_GetValue が呼び出される一方で、スクリプトのインターフェイスを取得するためにプラグインが初期化された後で が呼ばれます。
注意: Gecko はこれらの関数によって返された値をキャッシュしてプラグインのタイムスタンプが変化した場合にだけそれを呼びます。バグ 125469 を参照してください。
Mac OS
On the Mac OS プラットフォーム上では、プラグインフォルダはブラウザアプリケーションと同じフォルダ内にあります。プラグインはファイルタイプ NSPL によって識別されます。ブラウザが起動しているとき、ブラウザはプラグインフォルダのサブフォルダについてプラグインを検索してフォルダや NSPL ファイルへのエイリアスをたどります。プラグインのファイル名は NP で始まっていなければなりません。
プラグインによってサポートされた MIME タイプはリソースによって決められます。'STR#' 128 は交互に並ぶ文字列内で MIME タイプとファイルの拡張子を含んでいなければなりません。例えば:
| str 128 | MIME タイプ |
| 文字列 1 | video/quicktime |
| 文字列 2 | mov, moov |
| 文字列 3 | audio/aiff |
| 文字列 4 | aiff |
| 文字列 5 | image/jpeg |
| 文字列 6 | jpg |
いくつかの他の任意の文字列はプラグインについての有益な情報を含んでいるかもしれません。プラグインは 'STR#' 128 をサポートしていなければなりませんが以下の他のもののいずれもサポートを要求されません:
- STR#' 127 は STR#' 128 内のタイプに対応する MIME タイプのリストを含めることができます。例えば、以下の説明リストは前の例のタイプに対応しています: 文字列 1: 「QuickTime ビデオ」 、文字列 4:「AIFF オーディオ」や文字列 5: 「JPEG 画像フォーマット」
- STR#' 126: 文字列 1 はプラグインについて説明的なメッセージを含めることができます。HTML フォーマットのこのメッセージはブラウザの「プラグインについて」ページで表示されます。文字列 2 はプラグイン名を含めることができ、それゆえユーザの見る名前をディスク上のファイル名と違ったものにできます。
Mac OS X
Mac OS X 上では、Gecko が エントリポイントを見つけたら、リソースを見る代わりにこの関数によって返された情報を使用します。
Mac OS X のプラグインはセクション Gecko のプラグインの見つけ方に従って見つけられます。プラグインはファイルタイプ NSPL によって識別されます。
プラグインのインスタンスの描画
ページに描画する前に、プラグインはそれ自身の情報を提供し、ウィンドウかそれが描画する他の対象を設定し、再描画の準備をして、イベントを処理しなければなりません。
ウィンドウを持たないプラグインはそれ自身を描画するために以下の Netscape メソッドを呼ぶことができます:
- NPN_ForceRedraw: ウィンドウを持たないプラグインに対する描画メッセージを強制します。
- NPN_InvalidateRect: 再描画や再読み込みの前にウィンドウを持たないプラグイン内の領域を無効化します。
- NPN_InvalidateRegion: 再描画や再読み込みの前にウィンドウを持たないプラグイン内の領域を無効化します。
ブラウザは以下のプラグインのメソッドを呼べます:
- NPP_GetValue: プラグインに情報を問い合わせます。
- NPP_Print: インスタンスに対してプラットフォーム固有の印刷操作を要求します。
- NPP_SetValue: ブラウザの情報を設定します。
- NPP_SetWindow: プラグインが描画するウィンドウを設定します。
- NPP_HandleEvent: インスタンスにプラットフォーム固有のイベントを引き渡します。
プラグインは情報を問い合わせたり設定するために以下の Netscape メソッドを呼べます:
- NPN_GetValue: ブラウザの情報を取得します。
- NPN_SetValue: プラグインがブラウザの情報を設定します。
これらの処理についての情報に関しては、 描画とイベント処理を参照してください。
メモリの処理
プラグイン開発者はメモリを割り当てたり解放するのにプラグイン API で提供されているメモリ機能を利用できます。
- ブラウザからメモリを割り当てるのに NPN_MemAlloc メソッドを使ってください。
- NPN_MemAlloc で割り当てられたメモリを解放するのに NPN_MemFree メソッドを使ってください。
- （Mac OS のみで）メモリについて集約的な Mac Toolbox の関数を呼ぶ前にメモリを解放する NPN_MemFlush メソッドを使ってください。
ストリームの送信と受信
ストリームは URL とそれが含んでいるデータを表すオブジェクトです。ストリームはプラグインの特定のインスタンスと結びつけられています。しかしプラグインは一つのプラグインについて複数のインスタンスを持つことができます。ストリームバブラウザによって作り出されプラグインによって消費されます。個々のストリームはストリーム内のデータのフォーマットを識別する MIME タイプと結びついています。
ブラウザによって作り出されたストリームは自動的にプラグインのインスタンスに送られたりプラグインによって要求されたりすることがありえます。プラグインは以下の送信モードのうち一つを選択できます:
- 通常モード: ブラウザはデータが利用可能になったときプラグインに逐次的にストリームのデータを送ります。
- ランダムアクセスモード: ブラウザはプラグインがストリームの任意の場所から指定されたバイトの範囲を要求できるようにします。このモードはサーバのサポートが要求されます。
- ファイルモード: ブラウザはキャッシュ内のローカルファイルにデータを保存してプラグインにそのファイルのパスを渡します。
プラグインによって作り出されブラウザに送られるストリームはブラウザによって作り出された通常モードのストリームに似ていますが、逆です。ブラウザの通常モードのストリームでは、ブラウザはストリームが作成されたことを通知し更なる情報を押し込めるためにプラグインを呼びます。プラグインによって作り出されたストリームでは、逆に、プラグインはストリームを作りそれにデータを押し込めてそれを削除するために Netscape 関数を呼びます。
URL との連動
プラグイン API はネットワーク上の任意の URL からデータを取り出したり URL へデータを送信したり、他のドキュメントへのハイパーリンクを提供したり、HTTP を使用して CGI スクリプトへフォームデータを送信したり、FTP を使ってリモードサーバへファイルをアップロードしたりするのにプラグインが使えるメソッドを提供します。
- 表示する特定のブラウザウィンドウやフレームに URL を読み込んたり、新しいストリーム内でプラグインにその URL のデータを引き渡すようブラウザに要求するために NPN_GetURL を使ってください。
- The動作が完了したときにプラグインに結果を通知することを除いて NPN_GetURLNotify 関数は
NPN_GetURLのように動作します。 - メモリバッファやファイルから URL へデータを送るために NPN_PostURL を使ってください。サーバからの結果は表示する特定のブラウザウィンドウやフレームに送られるか、新しいストリーム内のプラグインのインスタンスに引き渡されます。
- 動作が完了したときにプラグインに通知することを除いて、 NPN_PostURLNotify 関数は
NPN_PostURLのように動作します。
これらのメソッドの使用についての情報に関しては、 URL を参照してください。
バージョンと UI 情報の取得
Netscape のプラグイン API メソッド群はプラグインに基本的なサービスを提供します。以下の Netscape メソッドを使えます:
- プラグインが表示されているブラウザを識別するには: この情報を読み込むために NPN_UserAgent メソッドを使ってください。
- プラグインとブラウザのバージョンとが互換性があり異なるバージョンに対する代替の処理を提供している可能性があるかと決めるために: メジャーおよびマイナー番号における変化を調べるために NPN_Version メソッドを使ってください。
これらのメソッドの使用についての情報に関しては、バージョン、UI とステータス情報を参照してください。
ステータス行へのメッセージの表示
機能的に、あなたのプラグインはブラウザにシームレスに統合され現在のブラウザの機能に追加したものとして動作します。プラグインがブラウザユーザインターフェイスの一部だとユーザに感じさせるため、ステータス行メッセージを提供することでブラウザの振る舞いをまねることができます。ステータス行にメッセージを表示するために NPN_Status メソッドを使ってください。
このメソッドの使用についての情報に関しては、バージョン、UI とステータス情報を参照してください。
プラグインのスクリプト化可能化
スクリプト化可能なプラグインは object や embed 要素を通してアクセスしたときに JavaScript や DOM から呼ぶことのできるメソッドを提供するために拡張されたプラグインです。以下の例を考えてください。ここではメディアプレイヤープラグインは SCRIPT タグ内で呼ばれる AdvanceToNextSong() メソッドで操作できます:
<object id="myPlugin"
type="audio/wav"
data="music.wav">
</object>
<script type="application/javascript">
var thePlugin = document.getElementById('myPlugin');
if (thePlugin)
thePlugin.AdvanceToNextSong();
else
alert("Plugin not installed correctly");
</script>
LiveConnect は 4.x NPAPI プラグインに対してこの種の振る舞いを提供します。しかし Gecko は現在 XPConnect を使っています。4.x Netscape ブラウザでスクリプト化可能にするために LiveConnect を以前使っていたプラグインは Gecko ベースのブラウザの基礎を形成している新しい XPCOM アーキテクチャーではこれが実現できる可能性はなくなりました。これは JRI/JNI スイッチが原因でバイナリレベルでの Java の互換性がもはや保証されなくなったからです。ブラウザのインターフェイス内の JavaScript が Netscape Communicator 4.x のプラグインに触れられるようにプラグインは現在 XPConnect と呼ばれる機構を使っています。
LiveConnect が Java と JavaScript との橋渡しであるのに対して、XPCOM はコンポーネントをブラウザからスクリプト化可能にするためのより全般的なフレームワークです。しかし、XPConnect を通してプラグインをアクセス可能なものにするために、Mozilla のコードにいくつかの変更が加えられて、
プラグインのスクリプト化可能性-JavaScript からプラグインのネイティブなメソッドを呼ぶ機能-についての情報に関しては以下を参照してください:
この記事ではプラグインのコードに対する必要な修正を説明して NPP_GetValue というこのスクリプト化可能性を提供するために更新された API の一つの実装の見本を提供しています。
プラグインは JavaScript がアクセスを提供するブラウザや他の DOM オブジェクトにメソッドを呼ぶことができることに注意してください。このプラグインの「双方向のスクリプト化可能性」は以下の記事で説明されています:
プラグインのビルド
いったん前のセクションで説明したようにプラグインをスクリプト化可能にするために専用のコードや追加のファイルを加えると、ビルドの過程はかなり簡単です。 plugins フォルダに入れる DLL に加え、アプリケーションディレクトリ内の適切な場所にタイプライブラリと追加のヘッダファイルも置かなければなりません。このセクションはより詳しくこれら追加のスクリプト化可能性を説明しています。
ビルド、プラットフォームやコンパイラ
ビルドリソースは主要なプラットフォームのすべてに対して SDK で供給されています。Unix プラットフォームに対する makefile、Windows や Mac OS X IDE に対するプロジェクトファイル、定義ファイル、リソースファイル、SDK 内のサンプルやあなた自身のプラグインプロジェクトのビルドに対する他のリソースがあります。Gecko プラグインはすべての主要なプラットフォーム上のよく知られたコンパイラでコンパイルすることもできます - これらのコンパイラの上手な使い方についてはもちろんこのマニュアルの範囲外ですけれども。
必要なリソース - 定義ファイル、ソースファイル、リソースファイル - はプラグイン SDK にあり、mozilla のソースツリーや単独でダウンロードできてビルドできるソフトウェアキットでも利用できます。 mozilla ソース内の mozilla/modules/plugin/tools/sdk/samples/basic にある基本的なプラグインのサンプルには主要なプラットフォーム上で基本的なプラグインをビルドするために必要なすべてのファイルがあります。
Mac OS X 用の Carbon 化されたプラグインのビルド
Mac OS X プラグインに対するビルドの過程は Mac「クラシック」プラグインや他のプラットフォーム上でのプラグインに対するものとよく似ています。しかし、Mac OS X プラットフォーム用のプラグインをうまくコンパイルするつもりならば注意しなければならないいくつかの違いがあります。
主な違いは npupp.h ヘッダで見ることができ、ここで TARGET_API_MAC_CARBON が真なのでプリプロセッサー変数_NPP_USE_UPP_ は FALSE か 0 に設定されています:
/* NPP_Initialize */
#define _NPUPP_USE_UPP_ (TARGET_RT_MAC_CFM && !TARGET_API_MAC_CARBON)
#if _NPUPP_USE_UPP_
typedef UniversalProcPtr NPP_InitializeUPP;
enum {
uppNPP_InitializeProcInfo = kThinkCStackBased
| STACK_ROUTINE_PARAMETER(1, SIZE_CODE(0))
| RESULT_SIZE(SIZE_CODE(0))
};
#define NewNPP_InitializeProc(FUNC) \
(NPP_InitializeUPP) NewRoutineDescriptor((ProcPtr)(FUNC),
uppNPP_InitializeProcInfo, GetCurrentArchitecture())
#define CallNPP_InitializeProc(FUNC) \
(void)CallUniversalProc((UniversalProcPtr)(FUNC),uppNPP_InitializeProcInfo)
#else
typedef void (* NP_LOADDS NPP_InitializeUPP)(void);
#define NewNPP_InitializeProc(FUNC) \
((NPP_InitializeUPP) (FUNC))
#define CallNPP_InitializeProc(FUNC) \
(*(FUNC))()
#endif
この場合、 npupp.h でも書かれている NPPluginFuncs 構造体内のすべての関数ポインタは実際の関数ポインタになり Carbon ランタイムによってサポートされていない「ルーチンディスクリプタ」ではありません:
typedef struct _NPPluginFuncs {
uint16 size;
uint16 version;
NPP_NewUPP newp;
NPP_DestroyUPP destroy;
NPP_SetWindowUPP setwindow;
NPP_NewStreamUPP newstream;
NPP_DestroyStreamUPP destroystream;
NPP_StreamAsFileUPP asfile;
NPP_WriteReadyUPP writeready;
NPP_WriteUPP write;
NPP_PrintUPP print;
NPP_HandleEventUPP event;
NPP_URLNotifyUPP urlnotify;
JRIGlobalRef javaClass;
NPP_GetValueUPP getvalue;
NPP_SetValueUPP setvalue;
} NPPluginFuncs;
最後に、Mac クラシックプラグイン内では、メインエントリポイントはプラグインの main 関数に対するランタイムディスクリプタである "mainRD" と呼ばれるエクスポートされたシンボルである必要があります:
#ifdef XP_MAC
/******************************************************************************************
* Mac platform-specific plugin glue stuff
*******************************************************************************************/
/*
* Main entry point of the plugin.
* This routine will be called when the plugin is loaded. The function
* tables are passed in and the plugin fills in the NPPluginFuncs table
* and NPPShutdownUPP for Netscape's use.
*/
#if _NPUPP_USE_UPP_
typedef UniversalProcPtr NPP_MainEntryUPP;
enum {
uppNPP_MainEntryProcInfo = kThinkCStackBased
| STACK_ROUTINE_PARAMETER(1, SIZE_CODE(sizeof(NPNetscapeFuncs*)))
| STACK_ROUTINE_PARAMETER(2, SIZE_CODE(sizeof(NPPluginFuncs*)))
| STACK_ROUTINE_PARAMETER(3, SIZE_CODE(sizeof(NPP_ShutdownUPP*)))
| RESULT_SIZE(SIZE_CODE(sizeof(NPError)))
};
#define NewNPP_MainEntryProc(FUNC) \
(NPP_MainEntryUPP) NewRoutineDescriptor((ProcPtr)(FUNC),
uppNPP_MainEntryProcInfo, GetCurrentArchitecture())
#define CallNPP_MainEntryProc(FUNC, netscapeFunc, pluginFunc, shutdownUPP) \
CallUniversalProc((UniversalProcPtr)(FUNC),
(ProcInfoType)uppNPP_MainEntryProcInfo, (netscapeFunc),
(pluginFunc), (shutdownUPP))
しかし、Carbon ランタイムプラグイン内では、「メイン」エントリポイントは同じプロトタイプを持つと期待されており、それをプラグインがエクスポートするのはよい形です。最低限、共有ライブラリの「メイン」エントリポイントはそのようなルーチンに設定されていなければなりません。
XPIDL コンパイラの取得と使用
プラグインに対するタイプライブラリやヘッダファイルを作成するために使わなければならない XPIDL コンパイラは mozilla のビルドの過程におけるいつもの産物です。mozilla のビルドの bin ディレクトリ内で、xpidl バイナリを見るべきです。以下の使用法の覚書内にあるように、欲しい出力の種類を指定するために -m オプションを使ってください。
使用法: ./xpidl [-m モード] [-w] [-v][-I パス] [-o basename | -e filename.ext] filename.idl
-a typelib へ注釈を出力する
-w 警告をオンにする（推奨）
-v 冗長モード (NYI)
-I ``#include "nsIThing.idl"'' に対するインクルードパスの最初にエントリを追加する
-o 出力に対して basename（例えば``/tmp/nsIThing''）を使う
-e 明示的な出力ファイル名を使用する
-m 出力モードを指定する:
header C++ ヘッダを生成する (.h)
typelib XPConnect typelib を生成する (.xpt)
doc HTML ドキュメントを生成する (.html)
java Java インターフェイスを生成する (.java)
例えば、プラグイン IDL ファイル nsITestPlugin.idl に対するヘッダファイルを作成するには、コマンドプロンプトで以下を入力するでしょう:
./xpidl -m header nsITestPlugin.idl
結果として生成されるヘッダファイル、nsITestPlugin.h、はそれから nsTestPlug.dll がビルドされるときにインクルードされるはずです。
タイプライブラリ
ヘッダファイルに加えて、プラグインに対するタイプライブラリも作らなければなりません。このファイル - 私たちの例では、nsITestPlugin.xpt - は XPIDL コンパイラから容易に生成することができ、ブラウザアプリケーションのプラグインサブディレクトリに置かれるはずです。
タイプライブラリはプラットフォーム、言語やプログラミング環境を横断できるようにする方法でオブジェクトのインターフェイスを公開する特別なバイナリ非依存のインターフェイスファイルです。タイプライブラリはランタイム字にインターフェイスについての情報を提供し、これは XPCOM のようなクロスプラットフォームのコンポーネントフレームワークで必要とされます。
nsITestPlugin.idl IDL に対するタイプライブラリファイルを作るには、コマンドプロンプトで以下を入力するでしょう:
./xpidl -m typelib nsITestPlugin.idl
プラグインのインストール
Netscape や Mozilla ブラウザの再設計で、プラグインや他のソフトウェアのインストール方法に劇的な変化がありました。Gecko は現在新しいブラウザコンポーネント、プラグイン、アプリケーションや他のあらゆるソフトウェアをインストールするのに使えるクロスプラットフォームのインストール API を提供しています。
この API は二つの方法のうち一つで使えます。下のネイティブインストーラーで説明されているように、ダウンロードしてプラグインに対するバイナリのインストーラを実行する小さなインストールスクリプトを作ることができます。あるいは下の XPI プラグインインストールセクションでドキュメント化された XPInstall API を使う完全なインストールを行えます。
API についての全般的な情報については、以下を参照してください: XPInstall API リファレンス
ネイティブインストーラー
プラグインは適切な領域にそれ自身をインストールするには XPInstall API を使わなければ行けません。プラグインは以前のように他のバイナリインストーラーを使ってもよく、その場合 XPIntall のアーカイブとそのインストールスクリプトは効果的にインストーラー実行可能ファイルに対する小さなラッパーとなり、そのバイナリをダウンロードしてユーザのシステム上でそれを実行します。以下のインストールスクリプトの例はどれくらい「ラッパー」を単純にできるかを概説します。
// DJ Double-Decker プラグインインストーラー
err = initInstall("DJ Double-Decker プラグインインストーラー", "DJDD", "0.9");
logComment("initInstall() が戻りました: " + err);
err = execute("djdd.exe", "", true);
logComment("execute() が戻りました: " + err);
if(!err)
{
err = performInstall();
logComment("performInstall() が戻りました: " + err);
}
任意のログ（すなわち、関数の戻り値を調べるために個々の主な段階の後に使われる logComment() メソッド）を付けても、インストールは十行以下です。
インストーラーをラップするためにこのような XPInstall スクリプトを使うことには、ブラウザと同じプロセスで実行することによる更なる利点があり、それはインストーラの実行可能ファイルを起動でき、すぐに制御を戻せるということです。
initInstall は名前やインストールについての他の情報を表すパラメータを伴ってインストールスクリプトを起動し始めます。次の行ではアーカイブ内に含まれるインストーラーを起動するために（ウィンドウオブジェクトはブラウザスクリプト内で暗黙的であるように、インストールスクリプト内では暗黙的に、Install オブジェクトのメンバである）execute() メソッドを使っています。performInstall() で実際のインストールが始まります。ローカルシステム上でインストーラーを実行するためにそれをインストールしなくてもよいということに注意してください。See theクロスプラットフォームのインストールについての更なる情報に関しては XPInstall API を参照して、XPInstall API がプラグインやそれを支えるファイルのインストールやブラウザへのプラグインの登録に必要な手続きを行っていることを示す、より詳細なプラグインのインストールに対する二番目の例を参照してください。
このスクリプトは XPI と呼ばれる特別なアーカイブに含まれています。分けられた実行可能ファイルが実際のインストールを行うとき、XPI の中身はインストーラーの実行可能ファイルと install.js インストールスクリプト以外の何物でもありません。
XPI プラグインインストール
サードパーティのインストーラーを使わずに、自分でインストールするために XPInstall API を使うこともできます。以下のスクリプトはどのプラットフォームでも動作し、Netscape 6 ブラウザ内の JRE 1.3 プラグインをインストールします。この種のスクリプトはあらゆるタイプのインストーラに簡単に応用できます。
// この関数はキロバイトでディスクスペースを検証します
function verifyDiskSpace(dirPath, spaceRequired)
{
var spaceAvailable;
// 与えられたパス上の利用可能なディスクスペースを取得します
spaceAvailable = fileGetDiskSpaceAvailable(dirPath);
// 利用可能なディスクスペースをキロバイトに変換します
spaceAvailable = parseInt(spaceAvailable / 1024);
// 検証をします
if(spaceAvailable < spaceRequired)
{
logComment("不十分なディスクスペース: " + dirPath);
logComment(" 必要 : " + spaceRequired + " K");
logComment(" 利用可能: " + spaceAvailable + " K");
return(false);
}
return(true);
}
var srDest = 38628;
var err = initInstall("Sun Java 2", "/Sun/Java2", "1.3");
logComment("initInstall: " + err);
var fPlugins= getFolder("Plugins");
logComment("プラグインフォルダ: " + fPlugins);
if (verifyDiskSpace(fPlugins, srDest))
{
err = addDirectory("JRE_Plugin_Linux_i386",
"1.3",
"jre-image-i386", // jar ソースフォルダ
fPlugins, // ターゲットフォルダ
"java2", // ターゲットサブディレクトリ
true ); // フラグを強制します
logComment("addDirectory() が戻りました: " + err);
// シンボリックリンクの作成: plugins/libjavaplugin_oji.so ->
// plugins/java2/plugin/i386/libjavaplugin_oji.so
var lnk = fPlugins + "libjavaplugin_oji.so";
var tgt = fPlugins + "java2/plugin/i386/ns600/libjavaplugin_oji.so";
var ignoreErr = execute("symlink.sh", tgt + " " + lnk, true);
logComment("execute symlink.sh "+tgt+" "+lnk+" が戻りました: "+ignoreErr);
if (err==SUCCESS)
{
err = performInstall();
logComment("performInstall() が戻りました: " + err);
}
else
{
cancelInstall(err);
logComment("cancelInstall() が戻りました: " + err);
}
}
else
cancelInstall(INSUFFICIENT_DISK_SPACE);
このスクリプトは Linux JRE プラグインをインストールしており Linux を起動していると想定しています。しかしプラットフォームの種類を調べたり、他のファイルの存在を調べたり、インストールスクリプト内で他の予備の関数を実行するために XPInstall API を使うこともできることに注意してください。
クロスプラットフォームな方法でプラグインのサブディレクトリを決めたり指定するための getFolder() 関数内での "Plugins" キーワードの使用にも注意してください。返されるオブジェクトである fPlugins は、ローカルのマシン上の XPI 内のファイルがインストールされる場所を実際に指定する addDirectory() 関数内でこのバイナリファイルのインストールに対するターゲットフォルダとして使われます。
プラグインのインストールと Windows レジストリ
Windows プラットフォーム上でのインストール手続きの重要な側面はレジストリキーの読み取りで、それによってローカルにインストールされた Gecko ベースのブラウザ数やインストールされているブラウザやプラグインに対しての設定のされ方を決めます。
InstallShield のようなネイティブな Windows のインストーラーを使うか XPInstall API を使ってインストールスクリプトを書くか（「XPI プラグインインストール」を参照してください）どうかにかかわらず、このセクションで説明するように、レジストリにアクセスしたり、プラグインについての情報を読み書きしたり、異なる Gecko のインストール目標に対してインストールをカスタマイズできます。
プラグインのインストールに影響を及ぼすレジストリキーは以下に列挙された多種の Gecko ベースの製品のサブキーです:
HKEY_LOCAL_MACHINE\Software\Mozilla
製品は Mozilla キーのサブキーとして載っています。Gecko ベースのブラウザを取得するためにこれらのサブキーを列挙でき、更にプラグインがインストールされているべきブラウザアプリケーションのディレクトリ、インストールされているバージョンなどのような重要な設定情報を読み込むためにこれらのサブキーを列挙できます。
Plugins キー-値のペアは Gecko ベースの製品に対してどこにプラグインがインストールされているべきかを示しています:
Plugins = C:\Program Files\Mozilla Firefox\plugins
最新の Gecko ベースの製品を除くすべてに対して、Components キー-値のペアは重要な情報の一部も保持しています: 上の「タイプライブラリ」で説明したように、Gecko ベースの製品では Components サブディレクトリ内にタイプライブラリファイルか XPT を置く必要があります。
Components = C:\Program Files\Mozilla Firefox\components
製品のサブキー（例えば、Mozilla/Mozilla Firefox 2.0.0.1）には PathToExe キー-値のペアをさらす bin サブキーがあります。
PathToExe = C:\Program Files\Mozilla Firefox\firefox.exe
どのようにレジストリからのこれらの値が異なるターゲットに対するインストールを導くために使うことができるのかについての更なる情報に関して XPInstall レジストリ操作の例を参照してください。
ネイティブなインストーラーを使っているならば、インストーラーは独自のやり方でレジストリにアクセスして更新します。XPInstall API を使っているならば、以下の例で説明するように、ソフトウェアをインストールすべきプラグインのサブディレクトリを見付けるために winReg 関数を使えます。
var winreg = getWinRegistry();
winreg.setRootKey(winreg.HKEY_LOCAL_MACHINE);
var index = 0;
var baseKey = "Software\\Mozilla";
while ( (MozillaVersion = winreg.enumKeys(baseKey,index)) != null )
{
logComment("MozillaVersion = " + MozillaVersion);
subkey = baseKey + "\\" + MozillaVersion + "\\Extensions";
pluginsDir = winreg.getValueString ( subkey, "Plugins" );
if ( pluginsDir )
logComment("pluginsDir = " + pluginsDir);
else
logComment("No plugins dir for " + baseKey + "\\" + MozillaVersion);
index++;
}
以上のインストールの例を組み合わせると、この種類の Windows レジストリのパースによって異なるプラットフォームやブラウザ上でのプラグインのインストールを簡単にすることができます。