付録  A 構成パスのマッピング

Desktop Manager の構成リポジトリの重要な設計照準の 1 つは、できるだけ多くの既存の構成形式による構成データのリポジトリとして機能できるような柔軟な設計です。

リポジトリに使用される構成形式は、構成データを「コンポーネント」に分割します。コンポーネントとは構成設定の集合です。1 つのコンポーネントに属する設定は、通常は一緒に使用され、相互に関連している可能性があります。多くの場合、特定のクライアントアプリケーション、ソフトウェアモジュール、アプリケーションドメインなどに関連付けられています。コンポーネントはその名前で識別され、たとえば org.openoffice.Inet のような構造的な名前を使用してパッケージの階層にグループ化されます。

各コンポーネントは階層構造になっています。この構造は 「ノード」と「プロパティー」で構成されています。ノードは、他のノードやプロパティーのコンテナの役割をする構成要素です。プロパティーは階層のリーフ要素で、1 つまたは複数の値が含まれています。ノードとプロパティーは名前で識別されるため、その親ノード内で一意でなければなりません。一意な名前があれば、そのコンポーネントとパス (たとえば org.openoffice.Inet/Settings/ooInetProxyType) によって、どのノードやプロパティーでも参照できます。

他の構成システムでは異なる構成形式が使用されています。他の構成システムの構成データは、APOC 構成形式を使用して構成レジストリに保存されますが、アプリケーションに対応する構成形式で渡す必要があります。APOC 形式を、アプリケーションが使用している形式に 1 対 1 でマッピングする必要があります。構文のマッピングは、対応 APOC アダプタによってサイレントに実行されます。テンプレート開発者に残された唯一のタスクは、構成データを構成プロファイルツリーに保存するときに正しい構成パスのマッピングを使用することです。これらのマッピングは、中央の構成リポジトリでクライアントのさまざまな構成システムの config オプションを区別するために必要です。次の構成システムには、アダプタによって定義および考慮される具体的なマッピングが定義されています。

• StarSuite/OpenOffice.org Registry (OOR。StarSuite と OpenOffice.org に使用)

• GNOME Configuration (GConf。GNOME アプリケーションに使用)

• Java Preferences (Java プログラムに使用)

• Mozilla Preferences (Mozilla に使用)

StarSuite/OpenOffice.org Registry (OOR)

OOR キー命名スキーマは Desktop Manager 構成リポジトリで使用されるスキーマなので、この構成システムでは適用の作業は必要ありません。

GNOME Configuration (GConf)

GConf の構成要素を APOC のコンポーネントとパスに変換するために、次のマッピングが実行されます。

• GConf 関連のコンポーネントにはすべて org.gnome の接頭辞が付けられる

• /apps/<subdir>/... はコンポーネントの接尾辞 apps.<encoded subdir> にマッピングされる

• /desktop/<subdir>/... はコンポーネントの接尾辞 desktop.<encoded subdir> にマッピングされる

• /system/<subdir>/... はコンポーネントの接尾辞 system.<encoded subdir> にマッピングされる

• /extra/<subdir>/... はコンポーネントの接尾辞 extra.<encoded subdir> にマッピングされる

• /extra/<keyname>/... はコンポーネントの接尾辞 extra にマッピングされる

• 命名規則に従っていないキーは、subdir と ooc があれば、コンポーネントの接尾辞 ooc.<encoded subdir> にマッピングされる

• /schemas/<keypath> はコンポーネント部品のスキーマにマッピングされ、上記の規則が残りのキーに適用される

• コンポーネント部品にマッピングされた GConf キーの subdirs はコンポーネント部品の制約に従ってエンコードされる

例 A–1 GNOME Configuration

• /apps/myapplication/sampleSub.Dir/sampleSetting は org.gnome.apps.myapplication/sampleSub.Dir/sampleSetting になる

• /desktop/sampleDir/sampleSub.Dir/sampleSetting は org.gnome.desktop.sampleDir/sampleSub.Dir/sampleSetting になる

• extra/sampleSetting は org.gnome.extra/sampleSetting になる

• /sample.Dir/sampleSetting は org.gnome.ooc.sample.Dir/sampleSetting になる

• /schemas/apps/gnome-setting/sampleSubDir/sampleSetting は org.gnome.schemas.apps.gnome-setting/sampleSubDir/sampleSetting になる

Java Preferences

Java Preferences のノード / キーのペアを APOC のコンポーネントとパスに変換するために、最初の 3 つのノードパス要素 (3 つより少ない場合はすべてのノードパス要素) が java.prefs に付加されてコンポーネント名が形成され、残りのノードパス要素とキーでパスが形成されます。ユーザー設定のみが考慮されます。

例 A–2 Java Preferences

• ノード /com/sun/star/configuration、キー someKey は java.prefs.com.sun.star/configuration/someKey になる

• ノード /com/acme/widget、キー someKey は java.prefs.com.acme.widget/someKey になる

• ノード /sample.Dir、キー someKey は java.prefs.sample.Dir/someKey になる

Mozilla Preferences

Mozilla の構成要素を APOC のコンポーネントとパスに変換するために、最初の要素 (名前に複数の要素が含まれていると想定) が org.mozilla に付加されてコンポーネント名が形成され、残りの名前がノードのパスとして使用されます。要素が 1 つだけの設定は、org.mozilla.ooc のそれぞれの名前の下に保存されます。

例 A–3 Mozilla Preferences

• mail.server.default.isSecure は org.mozilla.mail/server/default/isSecure になる

• sampleSetting は org.mozilla.ooc/sampleSetting になる