当然ながら、アプリケーションがシステム・バスからメッセージを受信したいのであれば、それに接続するのもありですが、それが送信できるメッセージは制約されます。一度アプリケーションがバスに接続されれば、matcherを追加することによりどのメッセージを受信したいかを記述しなくてはなりません。インターフェース、オブジェクト・パス、そしてメソッド(下記参照)を基に受信されるメッセージのルールをmatcherは指定します。これは取り扱いたいものへの取り扱いにアプリケーションが専念することを可能にし、メッセージの効率的なルーティングをうながし、バスを介する予期されるメッセージの洪水が全アプリケーションのパフォーマンスを(よたよたと這っているように映るほどに)低下させるのを防ぎます。オブジェクト実のところ、D-BUSはピアツーピア・プロトコルですので、全てのメッセージには送信元と宛先があります。これらのアドレスはオブジェクト・パスとして指定されます。概念上、D-BUSを使用する全てのアプリケーションはオブジェクトのセットを含み、メッセージはオブジェクト・パスに認識される特定の(アプリケーションでは無く)オブジェクトへ送信されます。そのうえ、どのオブジェクトも1つかそれ以上のインターフェースをサポート可能です。最初は、これらのインターフェースはJavaのインターフェースまたはC++の純粋な仮想クラスに見えます。オブジェクトが実装すると主張するインターフェースを実装しているかどうかをチェックするオプションが無く、サポートされるインターフェースをリストするようにオブジェクトを見る手段もありません。メソッド名にネーム・スペースを与えるためにインターフェースを使用しますので、単独のオブジェクトが同一の名前を共有するメソッドを複数持ちそれぞれのインターフェースが異なる場合もあり得ます。メッセージD-BUSのメッセージには、メソッド呼び出し、メソッド戻り、信号、そしてエラーの4種類があります。メソッドをD-BUSオブジェクト上で実行するには、メソッド呼び出しメッセージをオブジェクトに送信します。それはちょっとした処理を行ない、メソッド戻りメッセージまたはエラー・メッセージを戻します。何も戻さないと言う意味で、信号は他と一線を画します。(『信号戻り』メッセージやその他の種類のエラー・メッセージなどと言うものはありません。)メッセージは任意の引き数を持つことができます。引き数は強く型定義され、型には基本的なプリミティブ(ブール値、バイト数、整数)から高レベルの構造(文字列、配列、ディクショナリー)まで様々あります。サービスサービスはD-BUSの抽象では最もレベルが高く、それらの実装は現時点では流動的です。アプリケーションはバスと共にサービスを登録でき、それが成功すればアプリケーションはサービスを入手したことになります。他のアプリケーションは特定のサービスがバスに存在するかどうかを確認し、存在しなければそれを起動するようにバスに命令できます。サービスの抽象の詳細(特にサービス起動)は現在開発中であり、いつ変更が入っても不思議はありません。ユース・ケースD-BUSが比較的新しいにもかかわらず、それはとても素早く普及してきました。先述のとおり、デバイスがホット・プラグされるときに信号を送信するようにD-BUSサポートと一緒にudevを構築できます。どのアプリケーションもそれらのイベントにlistenし受信時に処理を実行します。USBメモリー・キーの挿入を検出し、自動的に装着します。デジタル・カメラが接続されれば、それは自動的に写真データをダウンロードします。実用性は遥かに低いのですがより面白い例として、JamboreeとRingalingの組み合わせが挙げられます。D-SUBインターフェース付きの簡素な音楽プレイヤーで、再生、次の曲へのスキップ、そして音量の変更などの操作が可能です。(シリアル・ポート)を開き何が受信されるかを監視する小さなプログラムです。『RING』と書かれたテキストを発見すれば、それはD-BUSを使い「音量を下げる」ようにJamboreeに伝えます。全体的な結果として発生する現象として、(コンピューターにモデムが接続されていて)電話が鳴れば、音楽の音量が下がります。これこそがコンピューターの用途の真髄なのです!コードの例D-BUSコードの用例をいくつか紹介します。busに信号を送信します。使用していますので、バス接続の詳細に自分自身で対処する必要はありません。busへの接続を入手し、D-BUSイベント取り扱いをGLibイベント・ループと統合します。それはsend_pingを呼び出す1秒間のタイマーを作成し、イベント・ループを開始します。オブジェクト・パス/com/burtonini/dbus/pingそしてインターフェースcom.burtonini.dbus.Signalから来る、新規のPing信号を構成します。それから文字列「Ping!」は引き数として信号に追加され、バスを介して送信されます。メッセージは標準的な出力として表示され、信号の送信をユーザーに知らせます。当然ですが、何もlistenしていない状態でバスを通して信号を垂れ流すのは賢くありません。出力する信号をlistenします。main関数は以前と同様に開始され、バスへの接続を作成します。それは、インターフェース(com.burtonini.dbus.Signal)付きの信号送信が通知されることを望み、signal_filterを通知の関数として設定し、そしてイベント・ループに突入することを記述します。突き合せと一致するメッセージが送信されるとき、signal_funcが呼び出されます。それはバスそのものからのバスの管理信号をも受信します。メッセージを受信するときにどう対処するかは、メッセージ・ヘッダーを検査する簡単なケースです。メッセージがバスの切断信号であれば、存在しないバスにlistenする意味が無いのでイベント・ループは終了します。(信号が取り扱われていると、バスは伝えられます。)次に、着信メッセージは予測されているメッセージと比較され、もしもそれが一致すれば、引き数は抽出され出力されます。着信メッセージがそのどちらでもなければ、「メッセージを取り扱わなかった。」とバスに伝わります。これらの2つの例では、(完全なのはいいのですが、サービスそして多数のオブジェクトを作成したいのであればくどいとも言える)低レベルのD-BUSライブラリーを使用しました。ここでより高レベルなバインディングの出番となります。D-BUSの論理モデルに遥かに近いプログラミング・インターフェースをもたらす開発中のC#そしてPythonラッパーがあります。例として、ここにあるのはPythonにあるより洗練されたping/listenの例の焼き直しです。Pythonバインディングは論理インターフェースのモデルを作成しますので、サービスから来るそれが無くては信号を送信するのは不可能です。そのようなわけで、この例はサービスをも作成します。send_ping)gtk.main()大半のコードが書かれているとおり自明の理でそのままです。バスへの接続を取得し、サービス(com.burtonini.dbus.SignalService)は登録されます。最低限のD-BUSオブジェクトが作成されオブジェクトから信号が毎秒ブロードキャストされます。codeよりも明確ですが、Pythonバインディングにはまだ手直しが必要です。(例えば、このままでは信号に引き数を追加する手段がありません。簡潔でより簡単に解読できます。一度述べますが、バインディングにも改善の余地があるのです。bus.add_signal_receiverを呼び出すとき、ユーザーはインターフェースとオブジェクト・パスを提出せねばならず、そうしなければ不格好なmatcherが作成されてしまいます。これはありふれたバグです。一度それが修正されれば、サービスとオブジェクト・パスの引き数は取り除かれ、コードの読みやすさを更に向上させます。call)システムです。D-BUSは現在非常に経験豊かなプログラマー集団により公的にかつ活動的に開発されています。早期の段階からD-BUSは先進的な人々から急速に受け入れられていますので、LinuxデスクトップでのD-BUSの将来はバラ色に明るいと言えます。D-BUSのホームページにて探せます。D-BUSはfreedesktop.org/の一環として開発されました。ORBitは、GNOMEにて使用されるCORBA実装です。(GNOMEコンポーネント・システムであるBonoboは、ORBit上にて構築されています。)KDEのRPC実装はDCOPです。Utopiaは、Linux内でのシームレスなハードウェア統合の構築を目標とし、D-BUSでそれを達成しています。Pythonにて使用できるかを示しました。DCOP(developerWorks、2004年02月)はKDEのプロセス間の通信プロトコルそしてそれを記述する方法を提供します。(CCM)はCORBA仕様そして(他のコンポーネント・モデルとの)CORBAインターオペラビリティーの輪郭を明確にします。zoneをご覧ください。BookstoreのLinux部門にて、Linux関連書物を割引価格でお買い求めください。コメントコメントを登録するにはサインインあるいは登録してください。