繰り返し述べてきたことだが、plistはFoundationフレームワークの各クラスと1対1で固くつながっており、それがplistの利便性の根拠となっている。言い換えれば、Foundationのないところにplistだけを持っていっても便利とはいえない。
Mac OS Xの基となったOPENSTEP for Machでもplistは用いられていたが、それはMac OS XのCocoaに相当するアプリケーション環境のみにとどまり、基盤となるOSやコマンドライン、各種サーバソフトウェアでは恩恵がなかった。
また、Mac OS XはOPENSTEPの直接の血統ではなく、OPENSTEPから受け継いだもの以上に旧Mac OSから受け継いだ要素の方が多く、plistの利便性が生かせる部分は少なくなっていくはずだった。しかし、AppleはCocoaのFoundationの良さをよく理解しており、CarbonやOSのレイヤーに至るまで同等の機能を実現する方向に突っ走ったのだ。
まず、Foundationをベースに記述言語をCに改めたCoreFoundation*が用意された。特別なランタイムを必要とするObjective-Cではなく、より低レベルな通常のC言語で再実装し汎用性を高め、処理速度の向上を実現した。当初はToolbox互換APIセットで旧Mac OSからの移行用という触れ込みだったCarbonだが、CoreFoundationを受け入れることでCFStringやCFDictionaryといったデータ構造はもとより、Cocoaのイベント処理の要であったRunLoop、Notificationなどの重要な要素を獲得し、文字どおりMac OS Xにおける「生命の源」となりつつある。
次に、OSの中にもFoundationを浸透させた。Mac OS XのデバイスドライバはIOKitと呼ばれるC++のクラスライブラリを利用して構築されるが、これは各ドライバ向けの機能だけではなく、汎用的なデータ構造としてOSString、Data、OSNumber、そしてOSArrayにOSDictionaryといったクラスを提供している。さすがにカーネルの中から直接plistは読み書きできないが、デバイスドライバの中には設定を記述するInfo.plistというplistがあり、その内容がこうしたクラスを用いて表現され、ドライバに渡されるのだ。
オープンソースという流れに関しても同様だ。CoreFoundationはDarwinの一部としてソースが公開されており、APSLに従う限り自由にソースを閲覧し、改造できる。CFStringやCFDictionaryのみならず、plistの読み書きについても同様だ。
ただ、CoreFoundationはリンクするには少々大きすぎる場合がある。例えば前回紹介したlaunchdだ。launchdはinitの代わりに起動する重要なデーモンであり、安定性を確保するにはできるだけ小さく独立性が高い方が好ましい。plistを読むためだけにCoreFoundationをリンクするのは大仰すぎるのだ。この問題を解決するため、launchdではその内部にlaunch_data_type_t*という小さなデータ構造を用意することで解決した。
そう、彼らは例えplistの使えない環境に相対したとしても、新しいエレメントを用意し新しいDTDを作るのではなく、Foundationの要素を植えつけplistを持って行くことを選択するのだ。
スティーブ・ジョブズが華やかな壇上でFoundationとplistについて述べることは決してない。しかし、この両者こそが「Mac OS Xの『魂』であることは疑念の余地はない」と言えるだろう。
現在では逆に、FoundationはCoreFoundationに対するObjective-C向けラッパーとなっている。
launch_data_type_tで用意されているのは、String、Integer、Real、Boolean、Array、Dictionaryといった基本データと、FileDescriptor(FD)、OPAQUE、ERRNOといったlaunchd独特のデータ構造である。また、plistの読み込みは外部コマンドのlaunchctlに任せている。launchctlは常駐しないため、CoreFoundationをリンクしており、CoreFoundationの持つplistの読み込み機能を利用しているのだ。
本記事は、オープンソースマガジン2006年1月号「Undocumented Mac OS X」を再構成したものです。
Copyright © ITmedia, Inc. All Rights Reserved.