本論文では、グラフィカル・インタフェイスの情報を X アプリケーション間で遣り取りするためのプロトコルについて述べる。Remote Access Protocol(RAP)を呼ばれる本プロトコルを使って、グラフィカル・アプリケーションに一連の指示を与えたり、同アプリケーションを調べたり、あるいは、我々のように、グラフィカル・アプリケーションを非視覚的表現に翻訳したりすることができる。アプリケーションが RAP を通じた遣り取りを始める方法について詳述し、プロトコル自体にどんなメッセージがあるのかを説明する。
本論文では、Remote Access Protocol あるいは RAP と呼ばれるアプリケーション間通信のためのプロトコルについて説明する。RAP を用いた場合、プロセス(エージェントagentと呼ぶ)は、別アプリケーションのインタフェイスの状態が変更した時にその通知を受けられるようになり、その上、他のアプリケーションの状態に変更を加えることも出来るようになる。
透過的に RAP を使用するための基本的な骨組みは、Xt ツールキットの中の新要素 HooksObject として、X Window System の第 6 版から組み込まれている。RAP プロトコル自体は、同プロトコルのランデヴ機構とともに、第 7 版で標準として採用されるよう提案が為されている。
RAP によって新種のアプリケーションを作りやすくなる。システムの中で RAP を利用する分野と云えば、インタフェイスの通訳がある(実際のところ、これこそが RAP の設計作業が始まった理由なのである)。RAP を通じて、エージェントはアプリケーションのインタフェイスに起きた変更の通知を受け取ったり、同インタフェイスを別の形式で提示したりすることができる(非視覚的形式も可能)。例えば、RAP エージェントを使って、車に搭載された電話から既存の X Window System アプリケーションに接続することや、あるいは、グラフィカル・アプリケーションを聴覚表現に翻訳して、目の見えない利用者に操作させることが出来る。
グラフィカル・アプリケーションのバッチ処理、自動試験、Editres のような対話式リソース編輯など、別種のアプリケーションも考えられる。我々の関心はインタフェイスの変換のためのソフトウェア・インフラストラクチャを用意することであったが、RAP が他のアプリケーションにも使えるものになるよう努めてきた。
本論文では、まず RAP 開発のキッカケとなった Mercator (メルカトル)の例を見る。これは X Window アプリケーションのために Georgia Tech が開発したスクリーン・リーダー(screen reader)である。次いで、RAP プロトコルの使用を可能とするインフラストラクチャについて見る。既存のインフラストラクチャと、追加すべきインフラストラクチャの提案とを扱う。その次には、RAP プロトコルの目標を述べる。同プロトコルを構成するメッセージ群を扱う節がこれに続く。最後に、RAP の現状と将来のプロトコル実装の指針を論じる。
RAP 開発のキッカケとしては、既存のグラフィカル・インタフェイスを非視覚的表現に変換する件が挙げられる。この変形を行うことが、Georgia Institute of Technology の取組みの一つ、Mercator Project(メルカトル計画)の目標であった。Mercator という取組みで構築してきたシステムは、盲であったり、視覚に大きな欠陥のあったりする計算機利用者でもグラフィカル・アプリケーションを利用できるようにするシステムである。同システムでは、映像の出力(graphical output)を非視覚的なもの(主として言語と非言語の音声)に変換可能である。また、アプリケーションを制御するための新たな入力手法(input modalities)も備わっている(例えば、同システムはキーボード入力を大抵のアプリケーションで「期待される」マウス入力に翻訳する)。このようなシステムは、貧弱な表示装置しかない場合や全く表示装置が存在しない場合にも(思いつくのは車の電話や PDA 機器)グラフィカル・アプリケーションを利用できるようにしてくれる、という点で有用である。
メルカトル計画(Mercator Project)を始めた時は、X プリケーションの状態変更に関する情報を攫むのに、徹頭徹尾外側から捕捉する手法を用いてシステムを作った。擬似サーバ・プロセスを使って、アプリケーションに出入りする X プロトコルの捕捉と生成の両方を行った。Editres 経由で操作する擬似サーバによって、X アプリケーションのインタフェイスとある程度遣り取りできた。しかしながら、擬似サーバを用いた手法には以下の問題があることが分かった。即ち、頻繁に変化する(highly dynamic)グラフィカル・インタフェイスを柔軟に取り扱うシステムは、擬似サーバでは構築し辛いということが分かった[1]。
二番目の版においては、Xt 自体に手を加える道を模索し始めた。Xt ならば、アプリケーション・インタフェイスに関する一層完全で高度な情報を取得できるからである。この手法の玄理は、アプリケーションにおいてウィジェットの階層やウィジェット・リソースの値に変更があった時、Xt がそれを報告するように仕込むことによって、エージェント・プロセスがアプリケーションのグラフィカル・インタフェイスの像(model)をより堅牢な形で構築できるようにすることにある。それに加えて、この手法では Xt の上層の様々なウィジェット・セットを無視することが出来る(つまり、新たなウィジェット・クラスが作られる度に毎回コードを変更する必要がない)[2]。
Remote Access Protocol 自体を論じる前に、重要だと思われる設計上の目標を提示しておく。
透過である(transparency)とは、RAP における変更が自身の動作に響くアプリケーションであっても、プログラマの介添え無しにプロトコルに入ることができるということである。これは、RAP に基づくサービスの輪に入るにあたって、アプリケーションの開発者側には何ら格別の作業が課されないことを意味する。
透過に実装するには、Xt と Xlib が作るインフラストラクチャを拡張し、通信の開始、リクエストへの応答、通知の生成、これら三つの全過程が Xt と Xlib の中で行われるようにしなければならない。しかしこの特性は、RAP を認識できるクライアントがプロトコルへの参加の仕方を自分で制御できるように作られている場合、同クライアントがそのように動くことを妨げない。また、セキュリティその他の理由があれば、クライアントには敢えてプロトコルに参加しないという選択肢も用意されている。
アプリケーションとエージェントが任意の順序でどちらの側からでも接続できるということは重要である。例えば、盲目の利用者は X セッションの開始にあたって、インタフェイスを翻訳するエージェントの立ち上げから始めるであろう。対話式のリソース・エディタの場合、エージェントは既にアプリケーションが動いている状況下で起動されるだろう。
最大限の柔軟性を確保し、種々のエージェントに対応するためには、起動順序が自由であることは必須条件である。
プロトコルとその開始のための手続きとは、複数のエージェントが同時に動作するのを妨げるべきではない。ある利用者が検査アプリケーションとリソース・エディタとインタフェイス翻訳器とを同時に走らせている場面を想像するのは容易い。プロトコルのインフラストラクチャは、一群のアプリケーションに対して任意の数のエージェントが接続することを可能にするものでなければならない。ここでいうエージェントには、RAP を使用するエージェントも、他のプロトコルを使用する者も含まれねばならない。
インタフェイスの変更に関する情報を遣り取りする RAP プロトコルが我々の主たる研究対象であったが、将来 RAP に必要とされているインフラストラクチャが他のプロトコルに利用されることもあり得る。したがって、RAP で用いる接続設定とフック(hook)とのインフラストラクチャは、任意の数のプロトコルが等しく利用できる形で作られるべきである。
現在の実装は Xt ツールキット用であり、研究成果が Xt 本体に多くの変更を齎しているが、RAP を他の Xt(非 Xt でも良い)ツールキットに実装してはならない理由はない。そのため、Xt 固有であったり、他のツールキットの枠組みで実装できそうになかったりする構造は、一切プロトコルに取り込まないことが重要である。
RAP はアプリケーション・インタフェイス上の変更全般を遣り取りできる道具であるが、エージェントが異なれば、同じように RAP に参加しているとしても必要となる情報は異なる可能性がある。例えば、インタフェイスを翻訳するシステムではインタフェイスの変更情報の全てを取得する必要がある一方、対話式リソース・エディタではリソースの中身の変更さえ通知されればそれで良い。したがって、RAP を通じてアプリケーションからエージェントへ送信する情報の型を制限する仕組みが欠かせない。
プロトコルは軽量であるべきである。存在することでクライアントの実行速度に悪影響を与えるべきではない。プロトコルに参加しないという選択をするクライアントもあるであろう。そのようなクライアントに利用しない機能の代価を払わせるべきではない。
グラフィカル・インタフェイスを非視覚的な等価物に翻訳するためには、それなりのインフラストラクチャが X Window System の中に備わっていなければならない。翻訳に必要な機能のいくつかは第 6 版で採用された。「既存のインフラストラクチャ」の節で取り上げるが、この機能は、プロトコルの接続が既に確立・初期化されていることを前提として、翻訳の実行を可能にするものである。しかし、現行の版ではプロトコルの確立と初期化を担う機能が未だに欠如している。「追加すべき必須インフラストラクチャ」の節では、この欠落を埋める方法について述べる。この追加機能によって、RAP プロトコルを利用するのに必要な全ての部品が揃うことになる。
今はプロジェクトの第二段階であるが、その間、一群のコード変更が X 協会(X Consortium)に提案され、第 6 版における協会標準として採用された。このコード変更によって、HooksObject と呼ばれる、新しく、private で(訳註：クラスが)、実装依存のウィジェットが Xt に導入された。フック・オブジェクトは、アプリケーションのディスプレイ接続と紐付けられており、コールバックの配列の集合を保持している(表 1 を見よ、"HooksObject Callback Lists")。このコールバックの配列群に入っている手続きは、アプリケーションのインタフェイスの状態に変更がある度に呼び出される。Xt は、適切なフック・オブジェクト・コールバックの配列を選択するように作られている。例えば、Xt は、新しいウィジェットを作成する度に、フック・オブジェクト中のコールバック配列「WidgetCreation」にあるコールバックを好きなだけ呼び出すことができる。ディスプレイ接続に紐付けられたフックオブジェクト[3]と、ディスプレイに紐付けられたシェル群とをアプリケーションから検索できるようにするため、いくつかの API が Xt に追加された。
| CreateHook | 新しいウィジェットの実体(instance)が作られた時に呼ばれる。 |
|---|---|
| ChangeHook | ウィジェットのリソース値が更新された時に呼ばれる。 |
| ConfigHook | ウィジェットの位置形状が実際に変わった時に呼ばれる。 |
| GeometryHook | ウィジェットの位置形状の情報が更新された時に呼ばれる。 |
| DestroyHook | ウィジェットの破壊作業の第一段階が完了した時に呼ばれる。 |
表 1、HooksObject Callback Lists
R6 の Xt ライブラリの変更では、「どんな」コードを各コールバック配列にインストールするのかは定めていない。同変更で加わったのは、インタフェイスに変更が生じる度に、Xt が一群のインストール済み手続きを呼び出すことを可能にするインフラストラクチャだけである。
R6 における Xt のフック・オブジェクトとともに、クライアント側の拡張フックが Xlib に追加された。拡張手続きは XESetBeforeFlush() を通じてインストールできる。この関数は、Xlib のリクエスト・バッファを放流する度に呼び出される[4]。この変更の目的は、インタフェイス変換システム(あるいは低水準のプロトコル情報に関心のあるアプリケーション)が XESetBeforeFlush を通じて低水準の X プロトコル情報の受け渡し手続きをインストールできるようにすることである。この低水準 X プロトコル情報は、これまでは擬似サーバに基づく手法に依らなければ取得できなかった。
Xt における変更と同じく、R6 の Xlib においてもフック BeforeFlush にインストールするコードは一つも定めていない。単にアプリケーションがコードのインストールのために用いるインフラストラクチャを作っただけである。
第 6 版のライブラリ Xlib と Xt に対する上記の変更は、二つの版のメルカトル・システムを通じて得た経験に基づいて為されたものである。この修正から使えるようになった情報型式(the types of information)は、実行中にグラフィカル・インタフェイスを非視覚的形式へ翻訳するのに必要なものである。
翻訳を可能にする枠組みは手元に揃ったので、実際に翻訳で必要な情報を遣り取りできるようなプロトコルの設計に目を向けよう。X11R6 から加わった Inter-Client Exchange Protocol(ICE)は、RAP を始めとしたクライアント間通信プロトコルの開発作業を容易くするものである。ICE は多くのプロトコルに共通の機能を備えている(接続の開設、リクエストの認証、接続の閉鎖、他にも多数)。これらの機能のお陰で、プロトコルの開発者は自作プロトコル固有のメッセージやメッセージ・ハンドラの設計に集中することが出来る。ICE で用意した汎用なプロトコルの機構に梃子を入れる形で開発する。ICE についてもっと詳しく知りたければ[5]と[6]を見る。
残念ながら、グラフィカル・インタフェイスの翻訳に「必要な」機構は第 6 版において導入されているものの、同翻訳を実行するに「十分な」機構は未だ備わっていない。欠けているのは、潜在的な RAP 通信の相手がプロトコルに参加可能な状態になった時、即座に同プロトコルを開始する役を担うプロセスの起動手段である。
この問題は RAP プロトコルだけのものではない。ICE を利用するプロトコル全てが通信プロセスの開始問題に直面している。数ある誂え物のプロトコルでは、これは指して問題にならない。回線の両端のクライアントは当然に利用するプロトコルを知っており、実行中の然るべき時点で、適切な ICE 関数呼出しを通じて、通信経路の設定へと歩を進めることができる。しかし、RAP プロトコルは同プロトコルの知識無しに書かれた既成の X クライアントとともに利用されるので、透過的な開始手段が重大な問題となる。
我々が第 7 版への採用を提言している解決策は、ICE Rendezvous Mechanism(ICE ランデヴ機構)である[7]。ランデヴ機構は、エージェントとクライアントの間に ICE 接続を確立する際に、両者の RAP プロトコルの知識を当然のものとして要求せずに済むよう設計してある。ICE に基づくプロトコルを使いたいクライアントは、同プロトコルの基となる ICE 接続を立ち上げるために、大まかに言って以下の手順に従う。
1. クライアントが共有したいプロトコルを ICE ライブラリに登録する。
2. クライアントがプロトコルの開始方(Protocol Originator)であれば、同者は能動的に相手との ICE 接続を作ろうと試みる。クライアントがプロトコルの受理方(Protocol Acceptor)であれば、同者は受動的に相手からの接続を待ち受ける。この過程での認証は任意である。
3. 一度 ICE 接続が作成されたら、開始方と受理方の間を Protocol Setup の要求メッセージと Protocol Reply の応答メッセージが行き来する。このメッセージの交換が、認証の行われる場合はそれも含めて、成功裡に終わると、目的のプロトコルのメッセージを遣り取りできるようになる。
回線の両側で知られている必要のある情報は二つ。
・共有したいプロトコル(本文書の場合、RAP)
・ICE ライブラリによって動的に割り当てられるネットワーク接続点(ネットワーク ID)。
この情報を転送するため、ClientMessage 機構の利用を提案している。同機構はプロトコル及びネットワーク ID の情報を運ぶ。そして、この情報は新たなデータ・オブジェクトやプロトコル初期化手続きの一覧表と併せて利用される。同一覧表に対してプロトコル手続きを追加(install)、削除、取得するため、複数の関数を用意する。
適切なプロトコル初期化手続きをインストールするのは、各プロトコル固有の ClientMessage イベント・ハンドラの仕事である。各プロトコルの開発者が用意したプロトコル初期化手続きによって、同プロトコルの開始要求を処理していく。プロトコル開始手続き中で必ず ICE 接続の設定を行わなければならないわけではない(但し RAP プロトコルでは、開始手続きの中でこの作業を行っている)。エージェントからの看視を受け入れられるクライアントは、自身の手続きを自身のアドレス空間にインストールしておかなければならない。
しかし、解決すべき点がまだ一つ残っている。そもそも RAP ClientMessage のイベント・ハンドラをどのようにインストールするのか。クライアントに RAP の知識を要求することなく全ての事を為すには、どうすれば良いのか。答えは各ツールキットに固有の VendorShell ソース・ファイルにある。Editres [8]の Client Message ハンドラは、全てのクライアントを Editres プログラムから透過的に問い合わせられるように、Athena ウィジェット・セットの VendorShell 実装の中にインストールされているが、これに倣って、RAP のクライアント・メッセージ・ハンドラを各ツールキット(Motif と Athena)の VendorShell 実装の中にインストールする。このやり方のお陰で、Motif や Athena に基づくクライアントは、そのツールキット・ライブラリに繋げておく(being linked)だけで、何れも RAP を認識できるようになる。
本論文のこの節においては、Remote Access Protocol の形式そのものを扱う。プロトコル中の各メッセージの意味論(即ち各メッセージが何を意味しているのか)、各メッセージが送信される状況、そして各メッセージの形式を述べる。以下に挙げるのは決定版でも最終版でもない。Mercator でも使用しているプロトコルの現行版を記したものである[9][10]。
個々のメッセージの説明で用いる「widget ID」という言葉は常に、アプリケーション中のツールキット・オブジェクトを指す 32-bit 且つ一意の識別子を表す。この 32 ビットの値は、RAP の Xt 実装においては直接ウィジェット ID に対応しているが、他のツールキットでは別の構成物を識別するために用ることもあるだろう。
また、ある種のツールキットでは実装してはいけないメッセージも存在する。例は DoActionRequest を見てほしい。
RAP のメッセージには三つの基本型がある。要求(requests、リクエスト)、返答(replies、リプライ)、通知(notifications)である。
リクエスト(要求)は、外部のエージェント・プロセスからアプリケーションへと向かう RAP メッセージである。これを用いて、アプリケーションにインタフェイスの情報を尋ねたり、同アプリケーションの何処かを操作したりする。
リプライ(返答)は、情報を求めてエージェントから送られてきた個々のリクエストに対する応答である。リプライはアプリケーションからエージェントへと向かう。
通知(notification)は非同期的なメッセージ(訳註：返答を要しない一方向のメッセージ)であり、これを用いて、アプリケーションのインタフェイスの状態変更を、関心のあるエージェントに通知する。通知の制御に関するリクエストを用いて、アプリケーションでどの通知を生成するかについて、取捨選択を行うことができる。
GetResourcesRequest メッセージを用いて、アプリケーションにウィジェット ID の配列を渡す。アプリケーションは、指定されたウィジェット群が持つリソースの名前と型の配列で応じる(GetResourcesReply を見よ)。
QueryTreeRequest は、アプリケーションに対して、同者のウィジェット階層全体を呼出し元のエージェントへ送り返すよう依頼する。返答は QueryTreeReply を使う。
一群のウィジェットにおける一群のリソースの値を求めるのに、GetValuesRequest を用いる。このメッセージは構造体の配列を運ぶ。各構造体にはウィジェット ID と、同ウィジェット中の値を取り出したいリソースの配列とが入る。アプリケーションは、要求された情報の入った GetValuesReply を生成する。
外部のエージェントは SetValuesRequest メッセージを用いて、一群のウィジェットの中のある一群のリソースの値を変更する。このメッセージは構造体の配列を使って情報を運ぶ。各構造体にはウィジェット ID と、リソース・値・型の組の配列とが入る。後者の配列によって、対象ウィジェットにおける変更対象リソース・新しい値・値の型の全てを指定する。
AddNotifyRequest を用いて、アプリケーションから送信される通知の要・不要を設定する。このメッセージでは HooksObject 中のコールバック配列の名前の配列を渡す。本リクエスト中で指定されたコールバック配列は、いづれも「要」("turned on")となる、即ち同配列を基に外部エージェントへの通知が生成される。
RemoveNotifyRequest を用いて HooksObject 内のコールバック群を「不要」とする("turning off")ことで、特定の通知を無効にする。AddNotifyRequest と同じく、無効にするコールバック配列の名前の配列を指定する。
ObjectToWindowRequest を用いて、ウィジェット ID から同ウィジェットの最上位ウィンドウを割り出す。このメッセージを通じて、割り出し作業を行いたいウィジェットの ID の配列を渡すと、アプリケーションは ObjectToWindowReply メッセージを返して来る。
WindowToObjectRequest を用いて、ウィンドウ ID から、同ウィンドウに結び付いた Xt ウィジェットの中の最上位のものを割り出す。このメッセージを通じて、割り出し作業を行いたいウィンドウの ID の配列を送信すると、アプリケーションは WindowToObjectReply メッセージを返して来る。
LocateObjectRequest メッセージを用いて、指定したオブジェクト群の、スクリーン上における位置を調べる。このメッセージの結果、アプリケーションから LocateObjectReply が返って来る。
GetActionsRequest を用いて、ウィジェットの一団に紐付けられている処理の一覧を取り出す。本メッセージはウィジェットの配列を運ぶ。
このリクエストを用いて、処理(action)を一つ呼び出す。同リクエストにはウィジェットと処理名(an action name)が格納され、この二つによって実行する処理を指定する。
このメッセージは、RAP の Xt 実装においては用意されないものと思われる。何故かというと、処理を直接呼び出すと Xt に基づくアプリケーションが不安定になる場合があるからである。
SelectEventRequest メッセージを用いて、どのイベント型がアプリケーションからエージェントへ送られるのかを制御する。エージェントとクライアント・アプリケーションの間に接続が確立する度に、手続き一つがクライアント側の WireToEvent 拡張スロットにインストールされる。これによって X イベント群をエージェントに転送することができる。本メッセージを使えば、どのイベントが実際に送信されるのかを選別できる。
SelectRequestRequest を用いて、アプリケーションからエージェントへと転送される X プロトコル・リクエストを選別する。リクエストは、クライアント側の BeforeFlush 拡張にインストールされた手続きによって捕捉され、同リクエストの型が SelectRequestRequest で選択されている場合には、エージェントに送付される。
エージェント側がクライアント・アプリケーションとの通信を終えたいと思った時、エージェントによって本メッセージが生成される。クライアントは適切な後片付け処理を実行して、その後に接続を断つものとする。
このメッセージは GetResourcesRequest を受けて生成される。同メッセージには構造体の配列が入る。各構造体は、先の要求を受けたウィジェットの ID と、同ウィジェットのリソース名・クラス・型の配列とから成る。
QueryTreeReply は QueryTreeRequest を受けて生成され、アプリケーションのウィジェット木構造を返す。同情報は構造体の配列の形をとり、各構造体には、ウィジェット ID、名前、クラス、ウィンドウ ID、そして親ウィジェットの ID が格納される。
このメッセージを用いて、指定されたウィジェットのリソース値の配列を問合せ元に返す。メッセージの形式は構造体の配列であり、各構造体には、要求を受けたウィジェットの ID、及び同ウィジェットに対して要求されたリソースの名前と値の配列が格納される。
ObjectToWindowReply メッセージは、ObjectToWindowRequest で要求したオブジェクトに対応するウィンドウの配列を返す。
WindowToObjectReply は、WindowToObjectRequest で渡したウィンドウに紐付けられたオブジェクトの配列を返す。
LocateObjectReply メッセージは、LocateObjectRequest で要求された各オブジェクトの X、Y 座標を返す。
GetActionsReply は、GetActionsRequest を受けて生成され、GetActionsRequest メッセージで指定された各ウィジェットの処理名(action name)の配列を運ぶ。
CreateNotify メッセージは、HooksObject の CreateHook コールバックの配列にインストールされたコードによって生成される。CreateNotify を用いて、新たなウィジェットが作成される度にエージェントへ通知を行う。本メッセージでエージェントに渡るのは、ウィジェット ID、名前、クラス、ウィンドウ ID、そして親ウィジェットの ID である。
ChangeNotify メッセージは、リソース値が更新される度に ChangeHook によって生成される。本メッセージでエージェントに送信されるのは、ウィジェット ID、リソース名、そして新しいリソース値である。
ConfigNotify メッセージは、ConfigHook コールバックが実行される度に関係するエージェント全てに送信される。このメッセージに格納される情報は、ウィジェットの位置形状(widget configuration)の変更点に関するものである。具体的には、ウィジェット ID、実際に変更があった箇所を特定するジオメトリ・マスク(geometry mask)、そして変更点を記載する XWindowChanges 構造体である。本メッセージは変更が行われた後に送信する。
GeometryNotify は、GeometryHook コールバックが実行される度に生成される。同コールバックが実行されるのは、Xt アプリケーションが位置形状に関する要求(geometry request)を行った時である。本メッセージには、XtWidgetGeometry 構造体の形で、結果として生じるウィジェットの位置形状の情報(widget geometry)が格納される。本メッセージは、位置形状の交渉(geometry negotiation)が完了した後に送信する。
DestroyNotify を用いて、エージェントに対してウィジェットが破壊された事を通知する。本メッセージは、「新たに破壊された」ウィジェットの ID を格納し、DestroyHook コールバックの配列を介して生成される。
RequestNotify によって、X プロトコル・リクエストをエージェントに渡す。実際に送信するリクエストは、SelectRequestRequest メッセージによって選別することができる。本メッセージは、一つ以上の通信形式の(wire-format) X プロトコル・リクエストを運ぶものであり、クライアント側の BeforeFlush 拡張にインストールしたコードによって生成される。
EventNotify によって X イベントをエージェントに回す。送信するイベントの型は SelectEventRequest メッセージで選別できる。本メッセージは、一つ以上の通信形式の(wire-format) X イベントを運ぶものであり、クライアント側の WireToEvent 拡張にインストールしたコードによって生成される。
メルカトル・システムの現在の実装は、RAP より前に作られた(けれども基本的な部分では似た)プロトコルを使って構築されている。このプロトコルは、標準の TCP/IP ソケットを通じて利用できる。RAP そのものの実装作業は、メルカトルで RAP を使えるようにする変更の実装作業とともに、進行中である。
Will Walker 氏は RAP の設計を担っており、既に ICE ランデヴ機構と RAP プロトコル・メッセージの実装作業を始めている。RAP に関する問題が扱われている公開フォーラムは x-agent の公開メーリング・リスト x-agent@x.org である。このメーリングリストは X 協会の後援を受けており、その目的は外部エージェント・ソフトウェアのために RAP と同様のプロトコルを開発することである。この取組みに加わりたい人は、次のアドレスにメッセージを送れば、同リストに参加することができる。
x-agent-request@x.org
メッセージの中身には「subscribe」一語を入れるものとする。同メッセージの題名は無視される。
昨年の X 技術会議(X Technical conference)において、Bull France(訳註：フランスの Bull 社?要確認) の Philippe Kaplan 氏と Anselm Baird-Smith 氏が K-Edit と呼ばれる 次世代の Editres プロトコルに取り組んでいることを明らかにした。K-Edit は「アプリケーションのユーザ・インタフェイスの状態を移し出すのに適した単純で多目的なプロトコルを作る試み」[11]である。K-Edit プロトコルと RAP プロトコルの目標は重なる部分が大きいので、昨年来、二つの取組みを合わせて共通プロトコルを作成することの実現性について、継続して議論が行われてきた。
追加すべきインフラストラクチャの節で述べた ICE ランデヴ・機構と ClientMessage ハンドラは、第 7 版で採用するように提案されるであろう。しかしながら、これらの提案が齎す変更点は、今日の R6 クライアントでも実装可能である。動的に連繋する(dynamically-linked)アプリケーションでは、ランデヴと ClientMessage に対応するよう修正されたソースから Intrinsics ライブラリを再構築するだけで良い。動的連繋によるアプリケーションは、次回の起動から RAP を認識するようになる。同者の動的に用いるライブラリが RAP を認識するように作られているからである。静的に連繋している(statically linked)クライアントは、新たにコンパイルされた Intrinsics の静的ライブラリに対して、再度連結される必要がある。しかし、RAP プロトコルの要件を満たそうと努力し続ける限り、どの道クライアント自体をソースコードの次元で修正する必要は生じないであろう。
RAP プロトコルの形式は今も発展中なので、現在のプロトコルと第 7 版締切り日のプロトコルの間でも変更があると考えて良い。ここで取り上げる必要がある分野として、リソースの型の交渉がある。アプリケーション中のリソースが用いる型は、特定の外部エージェントには知られていない可能性がある。しかし同時に、同アプリケーションが、リソースの型をエージェントの理解できる形式に変換する機能を備えていることもある。逆に、たとえ同エージェントが必要な変換器と連繋していなくとも、同者の内部に特定の型を変換する機能が備わっていることもある。したがって、エージェントとアプリケーションの間でリソースの型の交渉を行う手続きは、有用であろう。
X アプリケーションとエージェント・プロセスの間でインタフェイスの状態変更の情報を遣り取りするプロトコルについて述べた。このプロトコルは、対話型リソース編輯、スクリプトによる操作、試験実行、インタフェイスの翻訳など、多くの有用なエージェントを使用可能にしてくれる。
同プロトコルは一群のフック機能を基にして作られており、その中のいくつかは既に X Window System の第 6 版にも存在するが、未完成のものもまだまだある。
この計画への多数の方々の助力に感謝する。Tom Rodriguez 氏(以前は Georgia Tech 今は Sun Microsystems、RAP の基礎となったプロトコルを設計してくれた)、Bob Scheifler 氏、Donna Converse 氏、Ralph Swick 氏、Daniel Dardailler 氏、そして Kaleb Keithley 氏(X 協会所属)は、必要性の高かった設計案内を作ってくれた。また、Disability Action Committee on X(DACX)の方々にも感謝する。メルカトルに対する Sun Microsystems と NASA マーシャル宇宙航空センターの資金援助にも礼を述べたい。
Georgia Tech の「Graphics, Visualization, & Usability Center」で働く Keith Edwards 氏、Susan Liebeskind 氏、Beth Mynatt 氏。E メールアドレスは、keith@cc.gatech.edu、shl@cc.gatech.edu、beth@cc.gatech.edu である。連絡の取れる電話番号は (404)894-3658。Will Walker 氏は Digital Equipment Corporation(DEC)のソフトウェア・エンジニアである。氏のEメールアドレスは wwalker@zk3.dec.com。
[1] Elizabeth Mynatt and W. Keith Edwards. Mapping GUIs to Auditory Interfaces. In Proceedings of the Fifth ACM Symposium on User Interface Software and Technology(UIST), Monterey, CA, November, 1992.
[2] Elizabeth Mynatt and W. Keith Edwards. An Architecture for Transforming Graphical Interfaces. In Proceedings of the Seventh ACM Symposium on User Interface Software and Technology (UIST), Marina Del Rey, CA, November, 1994.
[3] Joel McCormack, Paul Asente, Ralph Swick. X Toolkit Intrinsics C Language Interface. X Consortium Standard. Version 11, Release 6.
[4] James Gettys and Robert Scheifler. Xlib C Language Interface. X Consortium Standard. Version 11, Release 6.
[5] Robert Scheifler and Jordan Brown. Inter-Client Exchange (ICE) Protocol, Version 1.0. X Consortium Standard. Version 11, Release 6. 1994.
[6] Ralph Mor. Inter-Client Exchange (ICE) Library, Version 1.0. X Consortium Standard. Version 11, Release 6. 1994.
[7] William D. Walker. An ICE Rendezvous Mechanism for X Window System Clients. Unpublished report, Disability Action Committee for X, 1994.
[8] Chris D. Peterson. Editres: A Graphical Resource Editor for X Toolkit Applications. In Proceedings of the Fifth Annual X Technical Conference, Boston, MA, January, 1991.
[9] W. Keith Edwards and Tom Rodriguez. Runtime Translation of X Interfaces to Support Visually-Impaired Users. In Proceedings of the 7th Annual X Technical Conference, Boston, MA, January 18-20, 1993.
[10] William D. Walker. Remote Access Protocol (RAP), Version 0.2. DACX Work In Progress. November 11, 1993.
[11] Philippe Kaplan and Anselm Baird-Smith. The K-edit System. Unpublished report available via http://zenon.inria.fr:8003/koala/k-edit.html.