Telepathy

Telepathy¹ は音声・動画・テキスト・ファイルなどを転送するためのリアルタイム通信フレームワークです。Telepathy がユニークなのは様々なインスタントメッセージプロトコルを抽象化する点ではなく、サービスとしての通信 (communications as a service) というアイデアを採用する点です。これは印刷がサービスであるのとちょうど同じで、様々な応用を可能にします。Telepathy は D-Bus メッセージングとモジュール化された設計を大いに利用してこれを達成しています。

サービスとしての通信を使えば通信をアプリケーションから分離できるので、このアイデアは非常に強力です。興味深い様々なユースケースがこれによって可能になります: 電子メールアプリケーションで連絡相手が在席中であるかを確認したり、ファイルブラウザからファイル転送処理を直接開始したり、アプリケーション内でネットワーク越しの協調動作を行ったりできます (Telepathy ではこの協調動作を Tube と呼びます)。

Telepathy は Robert McQueen によって 2005 年に作成され、その後いくつかの企業と個人コントリビューターによって開発・保守されてきました。McQueen が共同創設者の Collabora 社もそういった企業の一つです。

Telepathy フレームワークのコンポーネント

Telepathy はモジュール化されており、各モジュールは D-Bus のメッセージングバス (通常はユーザーのセッションバス) を通じて通信を行います。この通信の詳細は Telepathy の仕様書²で定義されます。Telepathy のコンポーネントの例を 図 20.1 に示します。

• Connection Manager は Telepathy と個別の通信サービスの間のインターフェースを提供する。例えば XMPP, SIP, IRC について一つずつ Connection Manager がある。新しいプロトコルのサポートを Telepathy に追加するには、新しい Connection Manager を書くだけで済む。

• Acount Manager サービスはユーザーの通信アカウントを保存し、リクエストがあったときには適切な Connection Manager を使ってアカウント同士の通信を確立する。

• Channel Dispatcher は Connection Manager がシグナルするチャンネルの接続要求を受け付け、テキスト・音声・ファイル転送・tubes といったチャンネルの種類にあったクライアントへ接続をディスパッチする。Channel Dispatcher は他にも、(Telepathy クライアントでない) アプリケーションが外向きのチャンネルをリクエストしたときにそれが適切なクライアントでローカルに処理されるようにするためのサービスも提供する。このサービスを使えば、電子メールアプリケーションなどのアプリケーションからテキストチャットを開始し、IM クライアントにチャットウィンドウを表示するといった処理が可能となる。

• Telepathy クライアントは通信チャンネルを監視する。IM や VoIP のクライアントやチャットロガーといったサービスも含む。クライアントは自身を Channel Dispatcher に登録し、そのとき処理・監視するチャンネルタイプのリストも伝える。

Telepathy の現在の実装では、Account Manager と Channel Dispatcher を実行するのは Mission Control と呼ばれる単一のプロセスです。

このモジュール化されたデザインは「一つのことをうまくやるプログラムを書け」という Doug McIlroy の哲学から来ています。この哲学にはいくつかの重要な利点があります:

• 頑強性: 一つのコンポーネントがクラッシュしてもサービス全体は影響を受けない。

• 容易な開発: 他に影響を与えることなく実行中のシステムのコンポーネントを入れ替えることができる。モジュールの開発バージョンを他の安定したモジュールと一緒にテストできる。

• 言語の独立: コンポーネントは D-Bus バインディングを持つ任意の言語で書ける。ある通信プロトコルの最良の実装がとある言語でしか利用できないなら、Connection Manager をその言語で書きさえすれば他の Telepathy クライアントから利用可能になる。同様に、ユーザーインターフェースを特定の言語で開発したい場合でもプロトコルへ完全にアクセスできる。

• ライセンスの独立: コンポーネントに互換性の無いライセンスを持つソフトウェアを使用できる。これは全てが一つのプロセスで動作する場合には不可能である。

• インターフェースの独立: 同じ Telepathy コンポーネントの上に複数のユーザーインターフェースを開発できる。デスクトップ環境とハードウェアデバイスに対するネイティブインターフェースがこれによって可能になる (GNOME, KDE, Meego, Sugar など)。

• セキュリティ: コンポーネントは個別のアドレス空間で最小限の権限で実行される。例えば Connection Manager は通常ネットワークと D-Bus セッションバスへのアクセスだけが必要とするので、SELinux などを使ってコンポーネントのアクセスを制限できる。

Connection Manager はたくさんの Connection を管理します。ここで Connection は通信サービスへの論理的な接続の表現であり、設定されたアカウント一つにつき一つの Connection が存在します。Connection には複数の Channel が含まれ、この Channel が通信を実際に行うメカニズムを表します。例えば IM 通話、音声・ビデオ通話、ファイル転送、あるいはその他のステートフルな操作が Channel となります。Connection と Channel については 20.3 節 で詳しく触れます。

Telepathy からの D-Bus の利用

Telepathy のコンポーネントは D-Bus メッセージングバス (通常はユーザーのセッションバス) を使って通信を行います。D-Bus は多くの IPS システムで見られる機能を提供します。サービスは /org/freedesktop/Telepathy/AccountManager³ のような細かく区分けされた名前空間にオブジェクトを公開し、このオブジェクトが様々なインターフェースを実装します。インターフェースも org.freedesktop.DBus.Properties や ofdT.Connection といった細かく区分けされた名前空間に定義され、ユーザーから利用可能なメソッド、シグナル、プロパティを提供します。

Telepathy が提供するインターフェース、メソッド、シグナル、プロパティは、XML をベースとして多く情報を持てるように拡張された D-Bus IDL で提供されます。この仕様書をパースしてドキュメントと言語バインディングが生成することもできます。

Telepathy サービスはバスにたくさんのオブジェクトを公開します。例えば Mission Control は Account Manager と Channel Dispatcher を公開し、他のオブジェクトがそのサービスにアクセスできるようにします。またクライアントは Client オブジェクトを公開し、Channel Dispatcher はこのオブジェクトにアクセスします。さらに Connection Manager は Account Manager が新しい接続のリクエストするときに使うオブジェクトを接続およびチャンネルごとに一つずつ作成します。

D-Bus オブジェクトはインターフェースを持つだけで型を持ちませんが、Telepathy はいくつかの方法を使って型をシミュレートします。まずオブジェクトのパスを見ればオブジェクトが接続か、チャンネルか、クライアントかといったことが分かります (ただしオブジェクトにプロキシをリクエストするユーザーはこれを知っています)。全てのオブジェクトはこの型に対する基底インターフェース (例えば ofdT.Connection や ofdT.Channel) を実装します。チャンネルではこれは抽象基底クラスのようになり、Channel オブジェクトは自身のチャンネル型を定義する具象クラスを持ちます。ここでもこのクラスは D-Bus インターフェースによって表されます。チャンネル型は Channel インターフェースの ChannelType プロパティを読むことで確認できます。

最後に、各オブジェクトはオプショナルなインターフェースをいくつか実装します。どれを実装するかはプロトコルと Connection Manager の機能によります。利用可能なインターフェースはオブジェクトの基底クラスの Interfaces プロパティを通して確認できます。

例えば odfT.Connection 型のオブジェクトのオプショナルなインターフェースには、ofdT.Connection.Interface.Avatars (プロトコルにアバターという概念がある場合)、odfT.Connection.Interface.ContactList (プロトコルが連絡先名簿を提供する場合 ――提供しないものもある)、そして odfT.Connection.Interface.Location (プロトコルが位置情報を提供する場合) などがあります。ofdT.Channel 型を持つ Channel オブジェクトが持つ具象クラスは ofdT.Channel.Type.Text, odfT.Channel.Type.Call, odfT.Channel.Type.FileTransfer といった名前のインターフェースを持ちます。Connection と同様に、オプショナルなインターフェースには odfT.Channel.Interface.Messages (チャンネルがテキストメッセージを送受信できる場合)、odfT.Channel.Interface.Group (チャンネルがマルチユーザーチャットなどの複数人をまとめるグループである場合) といった名前をしています。そのため例えばテキストチャンネルは最低でも ofdT.Channel と ofdT.Channel.Type.Text と Channel.Interface.Messages の三つを実装します。チャンネルがマルチユーザーのチャットであれば、これに加えて odfT.Channel.Interface.Group も実装します。

Connection オブジェクトが接続に関するインターフェースしか持っていないという確認を D-Bus 自身が行うことはありません (D-Bus は名前の付いたインターフェースであり、には型という概念が無いためです)。しかし Telepathy の仕様書に含まれる情報を使って Telepathy の言語バインディングをチェックすることはできます。

ハンドル

Telepathy はハンドルを使って識別子 (連絡先とルームの名前) を表します。識別子は Connection Manager が割り当てる符号無し整数であり、これを使えば連絡先あるいはルームが (Connection, handle type, handle) というタプルによって曖昧さなく表せます。

識別子の利用方法 (大文字と小文字の区別やリソースを取り扱い方) は通信プロトコルごとに異なるので、二つの識別子が同じかどうかを判定する方法がハンドルによってクライアントに提供されます。二つの識別子に対するハンドルをリクエストし、ハンドルの番号が合致すれば、識別子は同じ連絡先またはルームを指しています。

識別子の正規化規則はプロトコルごとに異なるので、クライアントで識別子やその文字列を比較するのは間違いです。例えば escher@tuxedo.cat/bed と escher@tuxedo.cat/litterbox は XMPP プロトコルにおいて escher@tuxedo.cat という同じ連絡先を指すので、同じハンドルを持ちます。クライアントがチャンネルをリクエストするときには識別子とハンドルの両方が使えますが、比較に使えるのはハンドルだけです。

Telepathy サービスの検索

Account Manager や Channel Dispatcher などの常に存在するサービスの名前は Telepathy の仕様書で定められており、変わることはありません。しかし Connection Manager やクライアントの名前は定められておらず、検索して見つける必要があります。

実行中の Connection Manager やクライアントの名前を記録するサービスは Telepathy に存在しません。その代わり D-Bus に接続して新しいサービスの通知を待つことになります。D-Bus デーモンは新しく名前の付いた D-Bus サービスがバス上に表れるとシグナルを送ります。Connection Manager とクライアントの名前は仕様で定まった接頭語で始まるので、新しい名前が表れるたびにそれをテストします。

この設計の利点は、内部状態が完全に無くなることです。Telepathy のコンポーネントは起動時に現在実行中のサービスの一覧をバスデーモンに尋ねます (バスデーモンにはオープンな接続に基づいた完全なリストがあります)。例えば Account Manager がクラッシュしたときには、実行中の接続の名前を調べればアカウントオブジェクトの関係を再構築できます。

Channel Dispatcher もこの方法で Telepathy クライアントを検索します。クライアントは ofdT.Client で始まり、ofdT.Client.logger のような名前をしています。

D-Bus トラフィックの削減

初期バージョンの Telepathy 仕様ではコンシューマーが必要な情報をメソッド呼び出しで取得するようになっており、D-Bus トラフィックを大量に消費していました。Telepathy の後のバージョンでは様々な最適化によってこの問題が解決されています。

まず、メソッド呼び出しは可能な限り D-Bus プロパティに置き換えられました。初期バージョンの仕様では GetInterfaces, GetChannelType といったオブジェクトプロパティの取得がメソッド呼び出しになっており、例えばオブジェクトの全てのプロパティを取得する処理が複数のメソッド呼び出しを使っていました。このような場合に D-Bus プロパティを使えば、標準的な GetAll メソッドを使って全ての情報を一度に取得できます。

さらに、チャンネルのプロパティの多くは最初から最後まで変化しません。例えばチャンネルの種類やインターフェース、接続先、リクエスト先などの情報がそうです。あるいはファイル転送チャンネルであれば、ファイルサイズやファイルの種類といった情報も変化しません。

そこでチャンネルの作成を予告するためのシグナルが作られました。このシグナルには新しいチャンネルの生涯変更されないプロパティを表すハッシュテーブルが含まれます。このハッシュテーブルを (20.4 節 で説明される) チャンネルプロキシのコンストラクタに渡せば、クライアントをこの情報の処理から解放できます。

ユーザーのアバターがバスを通して送られるときにはバイト配列として送られます。Telepathy はアバターを参照するのにトークンを使ってクライアントが不必要なアバターをダウンロードしないようにしているのですが、これはクライアント側から個別にリクエストを出す必要があることを意味します。つまりクライアントがアバターを個別にリクエストするときには RequestAvatar メソッドを使い、その返答としてアバターを取得します。このため、とある連絡先がアバターを更新し、そのことを Connection Manager がシグナルした場合には、そのアバターへのリクエストが複数回行われ、同じアバターのデータがバス上を複数回通ることになります。

この問題はアバターを直接には返さない新しいメソッドを作ることで解決されました。つまり、アバターを送り返す代わりにリクエストキューに入れておくということです。アバターをネットワークから取得したときに AvataRetrieved というシグナルが発生するようにしておき、クライアントはこのシグナルを待ちます。こうするとアバターのデータの転送は一度で済み、取得しようとしているクライアント全てで利用可能になります。クライアントのリクエストがキューにある場合には、AvatarRetrieved シグナルが発生するまで他のクライアントからのリクエストは無視されます。

連絡先名簿の読み込むなどして多数の連絡先を読み込むと、別名・アバター・機能・所属グループ・位置・住所・電話番号といった大量の情報がリクエストされます。以前の Telepathy ではこれが (GetAliases をはじめ多くの API が連絡先のリストを引数として取るために) 情報グループごとに情報を取得していたので、半ダースかそれ以上のメソッド呼び出しが発生していました。

この問題を解決するために、Contacts インターフェースが導入されました。これを使うと複数のインターフェースから集めた情報を一度のメソッド呼び出しで返すことができます。これに伴い Telepathy の仕様は拡張され、GetContactAttributes メソッドが返す名前空間で包まれたプロパティを表すための Contact Attributes が追加されました。クライアントは GetContactAttributes を連絡先のリストと所望のインターフェースと共に呼び出し、連絡先から「連絡先の属性から値へのマップ」へのマップを取得します。

コードを使うと分かりやすいでしょう。リクエストは次のような形をしています:

connection[CONNECTION_INTERFACE_CONTACTS].GetContactAttributes(
  [ 1, 2, 3 ], # 連絡先のハンドル
  [ "ofdT.Connection.Interface.Aliasing",
    "ofdT.Connection.Interface.Avatars",
    "ofdT.Connection.Interface.ContactGroups",
    "ofdT.Connection.Interface.Location"
  ],
  False # 連絡先への参照を保持しない
)

返るのは次の形をしたデータです:

{ 1: { 'ofdT.Connection.Interface.Aliasing/alias': 'Harvey Cat',
       'ofdT.Connection.Interface.Avatars/token': hex string,
       'ofdT.Connection.Interface.Location/location': location,
       'ofdT.Connection.Interface.ContactGroups/groups': [ 'Squid House' ],
       'ofdT.Connection/contact-id': 'harvey@nom.cat'
     },
  2: { 'ofdT.Connection.Interface.Aliasing/alias': 'Escher Cat',
       'ofdT.Connection.Interface.Avatars/token': hex string,
       'ofdT.Connection.Interface.Location/location': location,
       'ofdT.Connection.Interface.ContactGroups/groups': [],
       'ofdT.Connection/contact-id': 'escher@tuxedo.cat'
     },
  3: { 'ofdT.Connection.Interface.Aliasing/alias': 'Cami Cat',
        ...    ...    ...
     }
}

Connection, Channel, クライアント

Connection

Connection は Connection Manager によって作成され、一つのプロトコル/アカウントを使った接続を確立します。例えば XMPP アカウント escher@tuxedo.cat と cami@egg.cat に接続すると Connection が二つ作成され、それぞれが D-Bus オブジェクトとして表されます。Connection は通常 Account Manager によって現在有効化されているアカウントに対して作られます。

Connection は接続の管理・監視とチャンネルのリクエストのために必須の機能をいくつか提供します。その他にもプロトコルに応じて提供されるオプショナルな機能が多数あります。これらはオプショナルの D-Bus 機能として提供されるので、Connection の Interface プロパティに一覧となっています (一つ前の節で説明した通りです)。

Connection は Account Manager によって管理されることが多く、そのときには対応するアカウントのプロパティが使われます。Account Manager はアカウントごとにユーザーの着席状況を対応する接続と同期させることもできますし、アカウントに対する接続パスを提供することもできます。

Channel

Channel は通信を行う仕組みを表します。通常は IM 通話、音声通話、ビデオ通話、ファイル転送を表しますが、サーバーとのステートフルな通信 (例えばチャットルームや連絡先の検索) の提供に Channel を使うこともできます。各チャンネルは一つの D-Bus オブジェクトで表されます。

Channel はあなたが参加する二人以上のユーザーの間の通信を表します。Channnel にはターゲットの識別子が含まれ、これは一対一の通信の場合には相手の連絡先、複数ユーザー通信 (例えばチャットルーム) の場合にはルーム識別子となります。複数ユーザーの Channel は参加しているユーザーの連絡先を記録する Group インターフェースを公開します。

Channel は Connection に属し、Connection Manager によって (通常は) Channel Dispatcher を通してリクエストされます。あるいは、ネットワークイベント (チャットの受信など) を受け取った Connection によって作成され、その後 Channnel Dispatcher に渡されるということもあります。

チャンネルのタイプはその ChannelType プロパティによって定義され、チャンネルが必要とするコア機能、メソッド、プロパティ、シグナルが D-Bus インターフェース Channel.Type で定義されます (例えば Channel.Type.Text)。暗号化などのオプショナルな追加機能はチャンネルの Interfaces プロパティに追加インターフェースとして登録されます。ユーザーをマルチユーザーのチャットルームに接続するテキストチャンネルが持つインターフェースの例を 表 20.1 に示します。

チャンネル、チャンネルプロパティ、ディスパッチのリクエスト

チャンネルをリクエストするときには、作成するチャンネルが持つべきプロパティを収めたマップを渡します。通常のリクエストに含まれるのはチャンネルタイプ、ターゲットのハンドルタイプ (連絡先またはルーム)、そしてターゲットです。加えて転送するファイルの名前とサイズ、最初に音声や映像を表示するかどうか、会議通話に参加するチャンネル、連絡先の検索を行うべき連絡先サーバーといった情報も含めることができます。

チャンネルリクエストのプロパティは Telepathy の仕様で定められるインターフェースで定義されます。表 20.2 に示す ChannelType プロパティなどがその例です。プロパティは定義されたインターフェースの名前空間で修飾され、チャンネルリクエストに追加できるプロパティには Telepathy の仕様で requestable という印が付いています。

表 20.3 に示すもっと複雑な例は、ファイル転送チャンネルをリクエストします。リクエストするプロパティがインターフェースの名前で修飾されている点に注目してください (簡単のためプロパティをいくつか省略しています)。

チャンネルは作成 (create) または確保 (ensure) できます。チャンネルを確保するとは、存在しない場合に限って作成するということです。チャンネルの作成を行うと、全く新しい個別のチャンネルが作られるか、あるいは複数のチャンネルを作ることはできないというエラーが発生します。例えばテキストあるいは通話チャンネルは確保し (つまり、ある人物との通話は最大でも一つしか開けないということです。多くのプロトコルはそもそも同じ連絡先との多重の会話をサポートしません)、ファイル転送やステートフルな通信のチャンネルは作成することになるでしょう。

新しく作られるチャンネルは (リクエストされたかどうかに関わらず) Connection からのシグナルによって通知されます。このシグナルにはチャンネルの不変プロパティを表すマップが含まれます。このマップに含まれるプロパティはチャンネルが破壊されるまで変更されないと保証されています。不変とみなされるプロパティは Telepathy の仕様で決まっており、例えばチャンネルの種類、ターゲットハンドルタイプ、ターゲット、イニシエーター (チャンネルを作ったオブジェクト)、インターフェースなどが通常含まれます。チャンネルの状態といったプロパティはもちろん含まれません。

チャンネルの作成・確保時にチャンネルの不変プロパティを返すことで、そのチャンネルに対するプロキシオブジェクトが素早く作成できるようになります。情報のリクエストが不必要になるからです。表 20.4 に (表 20.3 のようにリクエストした) テキストチャンネルの不変プロパティを示します。TargetHandle や InitiatorHandle といったプロパティは省略しました。

プログラムは通常 Channel Dispatcher に向けてチャンネルのリクエストを行います。そのときはリクエストをしているアカウントとチャンネルリクエストを渡し、加えてハンドラの名前を渡すこともできます (プログラムからチャンネルを処理する場合に便利です)。接続ではなくアカウントの名前を渡しているので、必要な場合には Channel Dispatcher が Account Manager にアカウントをオンラインにするよう指示できるようになります。

リクエストが完了すると、Channel Dispatcher はチャンネルを名前の付いた Handler に渡すか、そうでなければ適切な Handler を検索します (Handler と他のクライアントについては以降で説明します)。Handler の名前を省略可能にすることで、最初のリクエスト以外にチャンネルと対話を行わないプログラムはチャンネルの処理を適切なプログラムに任せられるようになります (電子メールクライアントからテキストチャットを起動するなど)。

プログラムがチャンネルリクエストを Channel Dispatcher に送ると、Channel Dispatcher はそのリクエストを適切な Connection に転送します。Connection は NewChannels シグナルを送出し、これを受信した Channel Dispatcher がチャンネルを処理するクライアントを探します。外からやってきたリクエストされていないチャンネルも同様にディスパッチされ、Channel Dispatcher が送り出した先の Connection からのシグナルで処理が進みます。ただしこの場合には最初のプログラムからのリクエストはもちろんありません。

クライアント

クライアントは通信を送受信するためのチャンネルの管理・監視を行います。Channel Dispatcher に登録されるものであれば何でもクライアントと呼ばれます。クライアントには次の三種類があります (ただし一つのクライアントが同時に二つあるいは三つの種類を兼ねることもできます):

• Oversever: チャンネルと対話することなく監視だけを行う。チャットや動作 (VoIP 通話の発信および受信) のログによく使われる。

• Approver: 受信したチャンネルを受理するか拒否するかをユーザーに選択させる。

• Handler: チャンネルと実際に対話を行う。例えばテキストメッセージの通知および送信、ファイルの受信および送信など。Handler はユーザーインターフェースと結び付けられることが多い。

クライアントが D-Bus サービスを提供するときには、Client.Observer, Client.Approver, Alient.Handler という三つのインターフェースのどれかを使います。各インターフェースが提供するメソッドは Channel Dispatcher から呼び出され、observe, approve, handle すべきチャンネルに関する情報がクライアントへ伝達されます。

Channel Dispatcher はチャンネルをクライアントのグループに順番にディスパッチします。まずチャンネルは Observer に送られ、それらが全てが値を返してから Approver に送られます。その後 Approver のいずれかがチャンネルを受理または拒否すると、そのことが全ての Approver にそのことが伝わり、チャンネルが Handler にディスパッチされます。チャンネルのディスパッチが段階的に行われるのは、Handler がチャンネルの処理を始める前に Observer がセットアップの時間を必要とする場合があるためです。

クライアントはチャンネルフィルタというプロパティを公開します。Channel Dispatcher はこのプロパティを読み、クライアントがどのようなチャンネルを要求しているかを判断します。フィルタは少なくとも一つのチャンネルタイプとターゲットハンドルタイプ (連絡先あるいはルーム) を含む必要がありますが、追加で他のプロパティを持つこともできます。マッチングはチャンネルの不変プロパティを使って単純な比較で行われます。表 20.5 に一対一のテキストチャンネル全てとマッチするフィルタを示します。

クライアントのサービスは cfdT.Client という接頭語を持つ名前で公開される (例えば ofdT.Client.Empathy.Chat) ので、D-Bus を通じて検索できます。さらにクライアントはチャンネルフィルタを指定するファイルをインストールして、Channel Dispatcher にそれを読ませることも可能です。こうするとクライアントが実行されていない場合に Channel Dispatcher からクライアントを起動できるようになります。このようにクライアントを検索することで、Telepathy の他の部分を置き換えずともユーザーインターフェースが設定・変更可能になっています。

言語バインディングの役割

Telepathy は D-Bus API であり、したがって D-Bus をサポートする任意のプログラミング言語から利用できます。Telepathy には言語バインディングが必要ありませんが、利用を簡単にするバインディングを提供することはできます。

言語バインディングは二つの部分に分かれます。一つは低レベルバインディングで、ここには仕様書から生成されたコード、定数、メソッド名などが含まれます。もう一つは高レベルバインディングで、ここにはプログラマーが Telepathy を簡単に使えるようにするための手で書かれたコードが含まれます。高レベルバインディングの例は GLib や Qt4 バインディングであり、低レベルバインディングの例は Python バインディングとオリジナルの libtelepathy C バインディングです。ただし GLib と Qt4 には低レベルバインディングも含まれます。

非同期プログラミング

言語バインディングでは、D-Bus 越しのリクエストを行うメソッド呼び出しは全て非同期となります。メソッドを呼ぶとリクエストが作られ、返答はコールバック関数に返されます。これが必要なのは D-Bus 自身が非同期であるためです。

ネットワークやユーザーインターフェースのプログラミングと同様、D-Bus もイベントループを使って受信したシグナルやメソッドの返り値に対するコールバックをディスパッチします。D-Bus は GTK+ や Qt ツールキットで使用される GLib のメインループと上手く噛み合います。

D-Bus 言語バインディングの中には (dbus-glib のように) メソッドの返答が返るまでメインループがブロックする疑似的な同期 API を提供するものもあります。かつては telepathy-glib API バインディングも同様の API を公開していましたが、残念ながら疑似的な同期 API を使うと問題が起こることが判明したので、telepathy-glib からは削除されました。

Telepathy の C バインディングの (仕様から生成される) メソッド呼び出しは、最初 typedef によるコールバック関数を使っていました。ユーザーはこの型シグネチャを持ったコールバック関数を実装します。

typedef void (*tp_conn_get_self_handle_reply) (
    DBusGProxy *proxy,
    guint handle,
    GError *error,
    gpointer userdata
);

このアイデアは単純であり、C で上手く行きます。そのためその後のバインディングでもこの方法が使われ続けました。

最近になって、JavaScript や Python あるいは C# ライクな Vala といった GLib/GObject ベースの API を使う言語から GObject-Introspection というツールを通して Telepathy を使う人々が現れました。残念ながら上述のコールバックを他の言語に再バインドするのは非常に難しかったので、新しいバインディングが設計されました。新しいバインディングでは言語と GLib が提供する非同期コールバックの機能を利用するようになっています。

オブジェクトのレディネス

低レベル Telepathy バインディングのようなシンプルな D-Bus API では、D-Bus オブジェクトに対してメソッド呼び出しやシグナルの受信を始めるときに必要なのはそのオブジェクトに対するプロキシオブジェクトの作成だけです。オブジェクトのパスとインターフェースの名前を指定すればそれだけで使えるようになります。

しかし Telepathy の高レベルではプロキシオブジェクトが利用可能なインターフェースを知っておくべきなので、オブジェクトタイプの共通プロパティ (チャンネルタイプ、ターゲット、イニシエーター) を取得できることが望ましくなります。またオブジェクトの状態 (接続状態など) も取得・追跡できると便利です。

そのため、レディネス (readiness) という概念が全てのプロキシオブジェクトに対して存在します。プロキシオブジェクトに対してメソッド呼び出しを行って非同期的にそのオブジェクトの状態を取得し、状態が伝わってオブジェクトが準備完了になったときに通知を受けることができます。

全てのクライアントがオブジェクトの持つ全ての機能を実装するわけでもなければ知りたいわけでもないので、オブジェクトタイプのレディネスは機能ごとに分けられます。全てのオブジェクトが実装する機能はコア機能と呼ばれます。この機能はオブジェクトに関する重要な情報 (Interfaces プロパティおよび基礎的な状態など) を準備します。これ以外の状態に関してはオプショナルな機能がたくさん用意されており、例えば状態あるいはプロパティの追跡などが含まれます。プロキシから取得できる追加機能の具体例としては、連絡先の情報、(オブジェクトの) 機能、位置情報、チャットの状態 (「Escher がタイプ中...」など)、ユーザーのアバターがあります。

例えば、Connection オブジェクトのプロキシは次の機能を持ちます:

• インターフェースと接続状況を取得するコア機能

• リクエストできるチャンネルクラスやサポートする連絡先情報を取得する機能

• 接続を確立し、完了したら値を返す機能

プログラマーがリクエストを行うときには、使う機能のリストとその機能が全て利用可能になったら呼び出すコールバック関数を渡します。機能がその時点で利用可能である場合にはコールバック関数がすぐに呼ばれ、そうでなければ機能が取得されてから呼ばれます。

頑健性

Telepathy の大きな強みの一つが頑健性です。コンポーネントはモジュール化されており、一つがクラッシュしてもシステム全体が落ちることはありません。Telepathy を頑健にしている機能をここにあげます:

• Account Manager と Channel Dispatcher が自身の状態を復元できる。Mission Controll (Account Manager と Channel Dispatcher を含む単一プロセス) が開始するとき、その時点でユーザーのセッションバスに登録されているサービスの名前を調べる。その中の Connection が既知のアカウントと結び付いているなら、そのアカウントを (新しい接続を作ることなく) もう一度結び付ける。加えて稼働中のクライアントに対して処理しているチャンネルのリストを問い合わせる。

• クライアントが処理中のチャンネルを開いたまま消失すると、Channel Dispatcher はそのクライアントをリスポーンし、チャンネルを再送する。

  クライアントが何度もクラッシュするようであれば、Channel Dispatcher は異なるクライアントがあればそれを起動し、無ければチャンネルを閉じる (クライアントが処理できないデータを受信してクラッシュし続けるのを避けるため)。

  テキストメッセージの場合には、処理待ちメッセージのリストから消す前にクライアントからの受信完了通知が必要になるが、クライアントがメッセージの受信を通知するのはそれをユーザーが見たとき (フォーカスのあるウィンドウに表示されたとき) だけである。こうすることで、クライアントがメッセージのレンダリングを試みてクラッシュしたときにも、チャンネルはそれまでに表示しなかったメッセージを処理待ちメッセージのキューに留めておくことができるようにしている。

• Connection がクラッシュすると、Account Manager がそれをリスポーンする。当然ステートフルなチャンネルの内容は失われてしまうが、影響を受けるのはその Connection とそれを実行するプロセスだけであり、他の部分は影響を受けない。クライアントは接続の状態を監視し、クラッシュした場合には連絡先リストやステートレスチャンネルの情報をもう一度リクエストすればそれで済む。

Telepathy の拡張: Sidecar

Telepathy の仕様は通信プロトコルが持つ機能の多くをカバーしていますが、プロトコル自身が拡張可能である⁴場合もあります。Telepathy では仕様を変更せずともこういった拡張機能を使った通信が可能です。Sidecar と呼ばれる機能を使います。

Sidecar は通常 Connection Manager のプラグインとして実装され、指定された D-Bus インターフェースを実装する Sidecar をリクエストするメソッドがクライアントから呼び出されます。例えば XEP-0016 プライバシーリストの実装では com.example.PrivacyLists というインターフェースが実装されるでしょう。このメソッドはプラグインによって提供される D-Bus オブジェクトを返し、このメソッドがインターフェース (など) を実装します。このオブジェクトはメインの Connection オブジェクトとは別に存在します (Sidecar (側車) と呼ばれるのはこのためです)。

Connection Manager 内部の概観

ほとんどの Connection Manager は C/GLib 言語バインディングを使って書かれており、Connection Manager の開発を簡単にするための基底ベースクラスも用意されます。前述したように、D-Bus オブジェクトを公開するのは D-Bus インターフェースに対応するソフトウェアインターフェースを実装したオブジェクトです。Telepathy-GLib は Connection Manager, Connection, Channel オブジェクトを実装するための基底オブジェクト、および Channel Manager を実装するためのインターフェースを実装します。Channel Manager は BaseConnection から利用するファクトリであり、バスへ公開するチャンネルオブジェクトの初期化と管理を行います。

言語バインディングはミックスイン (mixin) も利用します。ミックスインをクラスに追加すると、追加機能の提供、API 仕様の抽象化、新しいあるいは廃止されたバージョンの API との互換性の提供といったことが単一のメカニズムを通して可能になります。最もよく使われるミックスインはオブジェクトに D-Bus プロパティインターフェースを追加するものです。他には ofdT.Connection.Interface.Contacts や ofdT.Channel.Interface.Group といったインターフェースを実装するミックスイン、現在バージョンに無いインターフェースを実装するミックスイン、古いまたは新しいテキストメッセージインターフェースを既存のメソッドを使って実装するミックスインがあります。

教訓

Telepathy は D-Bus を使った柔軟でモジュラーな API の好例であり、拡張可能で疎結合なフレームワークを D-Bus の上に構築する方法を示しています。デーモンによる中央管理を必要とせず、コンポーネントが再起動可能であり、そのときにデータが消失することもありません。Telepathy はバスのトラフィックを最小化して D-Bus を効率的に使う方法も示しています。

Telepathy の開発は反復的であり、D-Bus の使い方を少しずつ改善してきました。間違ったこともありましたが、その度に教訓を学びました。Telepathy のアーキテクチャの設計を通して私たちが重要だと実感したことをここにまとめます:

• D-Bus プロパティを使う。つまり、情報の受け渡しに小さな D-Bus メソッド呼び出しを何度も使わない。 全てのメソッド呼び出しにはラウンドトリップタイムが存在する。呼び出し (GetHandle, GetChannelType, GetInterfaces など) を何度も行うのではなくて、GetAll を呼んで D-Bus プロパティから全ての情報を一度に取得する。

• 新しいオブジェクトを通知するときに可能な限り多くの情報を提供する。かつて新しいオブジェクトの通知を受け取ったクライアントは、毎回そのプロパティを取得してすべきことがあるかどうかを判断していた。オブジェクト作成の通知シグナルに不変プロパティを含めておけば、ほとんどのクライアントはメソッド呼び出しをせずにこれを判断できる。さらに、すべきことがある場合にも不変プロパティをリクエストせずに済む。

• Contacts インターフェースで複数のインターフェースを同時にリクエストする。連絡先の情報を取得するときに GetAll ではなくて Contacts インターフェースを使えば全ての情報を一度にリクエストでき、D-Bus ラウンドトリップタイムを節約できる。

• 収まりの悪い抽象化を使わない。連絡先リストと連絡先グループを Group インターフェースを実装するチャンネルとして実装するというのは、新しいインターフェースを使わずに既存の抽象化を使っているので、良いアイデアに思えた。しかしこうするとクライアントの実装が困難となり、そもそも抽象化が適切ではなかった。

• API を将来必要になるものに合わせる。オリジナルのリクエスト API は使い勝手が悪く、非常に基本的なチャンネルのリクエストしかできなかった。そのため多くの情報を使ってチャンネルをリクエストする必要が生じたときにこの API を使い続けることができず、API を柔軟なものに置き換えなければならなかった。

1. http://telepathy.freedesktop.org/ あるいは開発者マニュアル http://telepathy.freedesktop.org/doc/book/ を参照してください。^[return]

2. http://telepathy.freedesktop.org/spec/^[return]

3. これ以降 /org/freedesktop/Telepathy と org.freedesktop.Telepathy を odfT と省略して書くことにします。^[return]

4. Extensible Messaging and Presence Protocol (XMPP) などがその例です。^[return]