X Session Management Protocol(日本語訳)

  最初に、批評・提言を通じて支援してくれた ICCCM と Intrinsics の作業部会の方々全員にお礼を申し上げる。また、次の方々に特別の感謝を申し上げる。アルファベット順に、Jordan Brown氏、Ellis Cohen氏、Donna Converse氏、Vania Joloboff氏、Stuart Marks氏、Ralph Mor氏、そして Bob Scheifler氏。

  X Session Management Protocol (XSMP) は、利用者がセッションを保存・復元する仕組みについて、標準規格を打ち立てるために考案された。セッション(session)とは、クライアントの集合であり、一つ一つのクライアントは独自の状態を持つ。セッションの管理はセッション・マネージャ(session manager)と呼ばれるネットワーク・サービスで行う。セッション・マネージャは利用者に成り代わってクライアントに命令を発する。この命令でクライアントに状態保存を促したり、クライアントを停止したりすることができる。クライアントは次のような形で自身の状態を保存する。即ち、後々クライアントを再起動することができ、かつ、まるで一度も停止されていなかったかのようにクライアントの処理を再開できる形で保存する。クライアントの「状態」には、編輯中のファイルの情報や、ファイル中の現在の書込み位置、未処理のデータ交換の開始点に関する情報等を含めることが可能である。クライアントを再起動する手段については、本プロトコルでは定めない。

  本プロトコルでは都合上、セッション・マネージャのクライアント(client)を「セッション・マネージャに対する接続」と定義している。クライアントは大抵、単一の X Window System ディスプレイ(display) に接続されたアプリケーションプログラムを実行するプロセスであるが、必ずしもこのような形態を採らなければいけない訳ではない。複数の X ディスプレイに接続されたクライアントも、接続される X ディスプレイを持たないクライアントも存在する。

  このプロトコルは X 協会(X Consortium)の ICE プロトコルを基層としており、接続管理と認証の処理は ICE プロトコルに則って行う。

  クライアントは XSMP に則って自身をセッション・マネージャに登録する。クライアントは起動時にセッション・マネージャへの接続を図り、動作している限り接続状態を保ち続ける。クライアントがセッションから外れる際には、接続を断つ前に適切なプロトコルメッセージを発する。何も知らせることなく接続が途切れた場合、企図せずクライアントが停止したものと見做される。

  クライアントの状態保存は、クライアントの複数の実体(instantiation)を一つ一つ独立に管理し得るような形で行われる必要がある。本プロトコルでは、クライアントの複数の実体を区別するために、クライアント ID (client-ID、クライアント識別子)と呼ばれる一意的な値を導入している。。例えば、クライアントが特定の実体の状態を記録する際、そのファイル名の一部にこの識別子を含めても良い。また、クライアント ID はクライアントを再起動するための命令文(the RestartCommand)の中にも記録する。こうすることでクライアントは再開後も同じ識別子を保持できるようになる。状態情報のうちの小さなものには、その記録を RestartCommand に入れられるものもある。例えば、X11 クライアントは、RestartCommand 中に「-twoWindow」指定を記載することで、再起動時に二つのウィンドウを表示する形で立ち上げるよう指示することができる。

  クライアントがセッション・マネージャのネットワークアドレスを知る方法はシステムによって異なる。POSIX システムでは環境変数 SESSION_MANAGER にネットワーク ID(ネットワーク識別子)を並べたものが入っている。各識別子は伝送方式(transport)の名前、スラッシュ、伝送方式特有のアドレスで構成されており、TCP/IP のアドレスなら次のようになる。

  ここでの hostname は完全修飾ドメイン名である。Unix Domain アドレスの場合。

  DECnet アドレスの場合。

  複数のネットワーク ID が存在する時は、コンマで区切って記載する。

  クライアントが起動したプログラムを当のクライアントに管理させたいこともあるであろう。例えば、メールプログラムはメールの文章を編輯するためにテキストエディタを立ち上げる。このように振る舞うクライアントはセッション・マネージャそのものである。起動したクライアントから起動されたクライアントへ適切な接続情報が送られる(例、環境変数 SESSION_MANAGER)。但し、その接続情報は最上位のセッション・マネージャに対するものではなく、起動者自身への接続に関するものである。

  どのクライアントにもプロパティの一群が紐付けられている。あるクライアントによって設定されたプロパティは他のクライアントからは見られない。このようなプロパティを使用してクライアントからセッション・マネージャへ、クライアントの現在の状態を通知する。クライアントが初めてセッション・マネージャに接続される時点では、まだいかなるプロパティも設定されていない。

  XSMP のメッセージでは、数種のデータの型を用いる。セッション・マネージャとクライアントの双方とも、常に独自のバイト順序でメッセージを記述し、そのまま送信する。そのため、どちらの側でも受信したメッセージのバイト列を並び替える必要が生じ得る。バイト列を並び替える必要があるか否かは、ICE プロトコルに則った処理を通じて、実行時に判断される。

  下表のデータ型の値が入るべき場所に不正な値が入れられた場合、メッセージの受け手から送り手に宛てて、エラーメッセージ「BadValue」を送信しなければならない。

  XSMP の手続きを始めるにあたって、クライアントはサーバに対して ICE の ProtocolSetup メッセージを送信する。XSMP のメッセージは全て、標準の ICE メッセージの形式に則っている。メッセージの主たる命令コード(major opcode)は、実行時、ICE の次元で決定され、XSMP に割り当てられる。交信するクライアントとセッション・マネージャの両者において、XSMP を示す主命令コードとして異なる値が割り当てられることもある。一度主命令コードの値が割り振られた後、交信当事者の双方は自身の発する XSMP メッセージ全てにおいて各々決まった値を使用することになる。メッセージの従たる命令コード(minor opcode)は、当のメッセージが XSMP のどのメッセージを伝えるものなのかを表す。

  クライアント ID は ISO Latin 1 (ISO 8859-1) 形式で符号化された XPCS 文字から成る文字列である。null 文字は使わない。クライアント識別文字列は、Register­Client メッセージと Register­ClientReply メッセージで使用する。

  クライアント ID は、後述する要素を順に繋げたものから成る。要素を繋げる際、区切り文字は用いない。全ての要素が所定の長さになるよう、各要素文字列の左側を文字「0」で詰める。１0進数は「0」から「9」までの文字を使って表し、１6進数は「0」から「9」までの文字と「A」から「F」までの文字を使って表す。

  このプロトコルは、後述するように一連のメッセージから成り立っている。メッセージ一つ一つの型は ICE 従命令コードで指定する。クライアントからセッション・マネージャへ送られるメッセージなのか、それともセッション・マネージャからクライアントへ送られるのかはメッセージの型毎に決まっており、各メッセージの説明欄に正しい方向が記載されている。また、メッセージのそれぞれの型に対して、有効な返答と起こり得るエラーメッセージの一覧が纏めてある。各エラー型に続く括弧の中に ICE の重症度が記されている。

RegisterClient [Client → SM]

  previous-ID: ARRAY8

  Valid Responses: RegisterClientReply

  Possible Errors: BadValue (CanContinue)
  

  クライアントの存在を登録するため、クライアントはセッション・マネージャに対してこのメッセージを送信しなければならない。もし前回のセッションから存在するクライアントを再開するのであれば、前回セッションで使用されていたクライアント ID を previous-ID 欄に入れなければならない。新規のクライアントの場合、previous-ID 欄のデータ長は 0 である。

  もし previous-ID が無効な値であれば、セッション・マネージャはクライアントに対して BadValue エラーメッセージを送信する。この時点でセッション・マネージャは登録受付状態へと復帰し、次の RegisterClient を待つことになる。その場合、無効な previous-ID を送ったクライアントは、previous-ID 欄を空(null)にして RegisterClient を再送する。

RegisterClientReply [Client ← SM]

  client-ID: ARRAY8
  

  client-ID 欄には、このクライアントが使うことになる唯一無二の識別子が記されている。クライアントが RegisterClient メッセージの previous-ID 欄において識別子を指定していた場合、client-ID は先に指定されていたものと等しくなる。previous-ID が空(null)であった時は、client-ID にはセッション・マネージャで新たに生成した唯一無二の識別子が入る。client-ID の形式は第六章で規定している。

  クライアントが Register­Client メッセージの previous-ID 欄を埋めなかった場合、セッション・マネージャは RegisterClientReply メッセージから間を置かずに SaveYourself メッセージを発しなければならない。その際、この SaveYourself メッセージでは「type = Local」、「shutdown = False」、「interact-style = None」、「fast = False」と設定する。クライアントは、他の Save­Yourself メッセージに対するのと同じように、このメッセージを処理する。

SaveYourself [Client ← SM]

  type: SAVE_TYPE
  shutdown: BOOL
  interact-style: INTERACT_STYLE
  fast: BOOL

  Valid Responses:
    SetProperties
    DeleteProperties
    GetProperties
    SaveYourselfDone
    SaveYourselfPhase2Request
    InteractRequest
  

  クライアントに状態の保存を促すため、セッション・マネージャからクライアントへこのメッセージが送られる。必要であれば、クライアントは状態を記録するファイルを編輯する。さらに必要であれば、クライアントは SetProperties メッセージを利用して、クライアントを再起動する際の様式や保存された状態を破棄する方法をセッション・マネージャに告知する。この処理の間、もし interact-style で認められていれば、セッション・マネージャへ InteractRequest メッセージを送ることで、クライアントは利用者と対話する許可を求めることができる。状態を保存し終えた後、もしくは状態保存が不可能な場合、プロパティが適切に設定されていれば、クライアントは SaveYourselfDone メッセージを発する。自分以外の他の全てのクライアントが各自状態変更を済ませた後に更なる情報保存を行いたいクライアントは、SaveYourselfDone の代わりに SaveYourselfPhase2Request を発する。この場合、クライアントは利用者とのやり取りを凍結し、 SaveComplete、Die、もしくは ShutdownCancelled メッセージを受信するまで待機しなければならない。

  もし interact-style の値が None に設定されているのであれば、クライアントは状態保存中に利用者とやり取りしてはならない。interact-style の値が Errors の場合、異常事態が起きた時に限って、クライアントと利用者とのやり取りを認めてもよい。interact-style が Any の時は、クライアントは自由に利用者とやり取りできる。利用者との情報交換は、Interact­Request メッセージを送ることから始まる。Interact­Request を寄越したクライアントのそれぞれに対して、セッション・マネージャは Interact メッセージを送信する。クライアントは Interact メッセージが届くまで、利用者とのやり取り全てを延期しなければならない。やり取りを終えたクライアントは、セッション・マネージャへ Interact­Done メッセージを送る。Interact­Request メッセージは、クライアントが Save­Yourself を受け取ってから Save­Yourself­Done を発するまでの間、いつでも送信することができる。

  特殊な状況では、利用者と何度もやり取りをしなければならないこともあろう。SaveYourselfDone を送る前であれば、クライアントは Interact­Request - Interact - InteractDone の一連の手続きを必要なだけ実施することができる。

  クライアントが、先着の Save­Yourself に対して Save­Yourself­Done を返していないうちに、新たな Save­Yourself を受信した場合、まず Save­Yourself­Done を送信しなければならない。そのようにした後には、新着の Save­Yourself に対して適宜返答してもよい。

  type 欄では、情報がどのような形で保存されるのかを指定する。値は Global、Local、もしくは Both のどれかである。 Local 型であれば、アプリケーションは自身の現在状態を映すようにプロパティを更新し、Save­Yourself­Done を送信し、その上で元の処理を続行するようにしなければならない。この作業で保存される情報は、クライアントの利用者から見た状態を復元するのに十分なものであるべきであって、他の利用者から見える状態に変更を加えるものは保存を控えるべきである。利用者がクライアントに、その全てのデータを恒久的かつ広域アクセス可能な記録領域へ書き込ませたい時には、Global 型が選ばれる。Both 型であれば、クライアントは両方の作業を行う。Both が指定された場合、クライアントはまず恒久的な記録領域にデータを書き込み、それからセッション・マネージャのプロパティ群を更新する。

  shutdown 欄には、システムが終了作業中であるか否かを記す。

  (訳註：shutdown の値が真であれば？、)クライアントは必ず状態を保存しなければならず、その後 SaveComplete、Die もしくは Shutdown­Cancelled が届くまで利用者とのやり取りを禁じなければならない。保存の後に利用者が行ったことは全て消えてしまうからである。

  fast 欄では、クライアントができる限り急いで自身の状態を保存しなければならないのか、そうでもないのかを指定する。例えば、電源が落ちそうであることをセッション・マネージャが知っている場合、fast の値は True に設定される。

SaveYourselfPhase2 [Client → SM]

  Valid Responses:
    SetProperties
    DeleteProperties
    GetProperties
    SaveYourselfDone
    InteractRequest
  

  セッション・マネージャは SaveYourselfPhase2Request メッセージを送ってきたクライアントに対して上のメッセージを送信する。このメッセージはクライアントに次のことを通知する。即ち、他の全てのクライアントは状態変更を終えたので、それらに関わる状態情報を保存してもかまわない、ということを通知する。

  クライアントは、必要であれば自身の状態をファイルに書き込み、また、必要であれば、SetProperties を用いて、セッション・マネージャに自身の再起動様式と保存された状態情報の破棄方法とを通知する。この作業の間、クライアントは InteractRequest メッセージを送信して、利用者とやり取りを行うための許可を求めることができる。これを認めるのは、エラーが発生し、その解消に利用者とのやり取りが必要な時に限るべきである。状態を保存し終えた後、もしくは状態保存が不可能な場合、プロパティが適切に設定されていれば、クライアントは SaveYourselfDone メッセージを発する。

SaveYourselfRequest [Client → SM]

  type: SAVE_TYPE
  shutdown: BOOL
  interact-style: INTERACT_STYLE
  fast: BOOL
  global: BOOL

  Valid Responses: SaveYourself
  

  アプリケーションはこのメッセージをセッション・マネージャへ送信し、手拓作業(checkpoint)を要請する。この要請を受けたセッション・マネージャは、返答として SaveYourself メッセージを生成することができる。その際、引数欄で指定された値をそっくり流用することも可能である。

  もし global の値が True であれば、結果として返される SaveYourself は全てのアプリケーションに送信される。global の値が False であれば、結果として返される SaveYourself は Save­Yourself­Request を発したアプリケーションに対して送信される。

InteractRequest [Client → SM]

  dialog-type: DIALOG_TYPE

  Valid Responses: Interact ShutdownCancelled

  Possible Errors: BadState (CanContinue)
  

  手拓作業(checkpoint)やセッション保存作業の間、一度に一つのクライアントだけが利用者とやり取りする特権を与えられる。もし他のクライアントによって終了作業が取り消されていなければ、InteractRequest メッセージを受け取ったセッション・マネージャは、後のいづれかの時点で Interact メッセージを発する。

  dialog-type 欄には Errors と Normal のどちらかを指定する。前者はクライアントにエラー時の対話画面(error dialog)を起動させたい場合に、後者は通常の対話画面を起動させたい場合に指定する。

Interact [Client ← SM]

  Valid Responses: InteractDone
  

  このメッセージを受け取ることで、クライアントは利用者とやり取りする特権を与えられる。利用者とのやり取りが終わった時、終了作業取消し(shutdown cancel)のメッセージが届いていなければ、クライアントはセッション・マネージャに InteractDone メッセージを送信しなければならない。

InteractDone [Client → SM]

  cancel-shutdown: BOOL

  Valid Responses: ShutdownCancelled
  

  このメッセージを通じて、クライアントはセッション・マネージャへ利用者との交信の完了を通知する。

  cancel-shutdown 欄が True に設定されるのは、利用者が終了作業全体の取り止めを求めた時である。Cancel-shutdown を True に設定することが許されるのは、元となる SaveYourself メッセージの shutdown 欄に True が指定され、かつ、interact-style 欄に Any か Errors が指定されている場合に限られる。それ以外の場合には、cancel-shutdown の値は False でなければならない。

SaveYourselfDone [Client → SM]

  success: BOOL

  Valid Responses:
    SaveComplete
    Die
    ShutdownCancelled

  

  クライアントはこのメッセージを送信して、自身の状態を表すプロパティの全てが更新されたことを知らせる。SaveYourselfDone を送信した後、SaveComplete、ShutdownCancelled もしくは Die メッセージを受信するまで、クライアントは状態変更を控えなければならない。SaveYourself の作業が成功裡に終わった場合、クライアントは success 欄の値を True に設定する。そうでなければ False に設定する。

SaveYourselfPhase2Request [Client → SM]

  Valid Responses:
    ShutdownCancelled
    SaveYourselfPhase2

  

  クライアントはこのメッセージを送信し、他の全てのクライアントが静遊状態(quiescent)になったら知らせてもらう必要があること、それまで現状態を保持し得ることを伝える。

Die [Client ← SM]

  Valid Responses: ConnectionClosed
  

  セッション・マネージャは、クライアントを停止したい時、Die メッセージを送信する。クライアントは停止する前に ConnectionClosed メッセージを返信する。返信後はいつでもセッション・マネージャとの接続を断ってよい。

SaveComplete [Client → SM]

  Valid Responses:
  

  手拓作業(checkpoint)を終えたセッション・マネージャは各クライアントへ SaveComplete メッセージを送信する。以後、クライアントは自由に状態を変えることができる。

ShutdownCancelled [Client ← SM]
  

  進行中であった終了処理(shutdown)が中断されたことを示す。クライアントはまるで終了処理が存在しなかったかのように元の動作を続けることができる。未だ SaveYourselfDone を送信していないのであれば、クライアントは次の動作のどちらかを行うことができる。即ち、保存作業を中断して success 欄の値を False とした SaveYourselfDone を送信するか、もしくは、保存作業を続けて、その結果を success 欄に反映した SaveYourselfDone を送信する。

ConnectionClosed [Client → SM]

  reason: LISTofARRAY8
  

  クライアントの終了が決定したことを通知する。この後、直ちに接続を断つものとする。

  reason 欄には、クライアントがセッションから外れる理由を、Compound Text 形式の文字列の配列で記す。クライアントの中座が利用者にとって想定されていたものであれば、大抵は ARRAY8 から成る配列の長さは 0 である。一方、クライアントが予期せぬ致命的なエラーに見舞われた場合、エラーメッセージ(通常は POSIX システムの stderr に書き込まれるもの)をセッション・マネージャへ送信する。このエラーメッセージでは一行につき一つの ARRAY8 が当てられる。reason 欄の内容を利用者に表示するのはセッション・マネージャの仕事である。

  このメッセージを送り出した後、当のクライアントはセッション・マネージャに対して追加の XSMP メッセージを送信してはならない。

SetProperties [Client → SM]

  properties: LISTofPROPERTY
  

  指定されたプロパティ群のそれぞれに指定された値を設定する。既存のプロパティの中、Set­Properties メッセージで挙げられなかったものは変化しない。予め役割を決められているプロパティも存在する。第十一章 予め定義されているプロパティ群 を見よ。

  プロトコルの仕様として、標準で定義されていないプロパティの名前には頭にアンダースコアを付けるよう勧告している。組織間での衝突を防ぐために、接頭辞を付加する(例、_KPC_FAST_SAVE_OPTION)。組織用の接頭辞は X Registry に登録するものとする。アンダースコア以外の文字から始まるプロパティ名は全て、XSMP で将来使用されるかもしれないので、使わずに残しておく。

DeleteProperties [Client → SM]

  property-names: LISTofARRAY8
  

  名前が挙ったプロパティを削除する。

GetProperties [Client → SM]

  Valid Responses: GetPropertiesReply
  

  このメッセージを発したクライアントの全プロパティの値を寄越すよう、セッション・マネージャに要請する。

GetPropertiesReply [Client ← SM]

  values: LISTofPROPERTY
  

  このメッセージは GetProperties メッセージに対する返信であり、全プロパティの values (訳註：名前、型、値？)が入っている。

  メッセージの受信側で異常事態に気づいた時は、受信側から送信元へ ICE エラーメッセージを送る。XSMP で使用するエラーは二種類しかない。BadValue と BadState である。両方とも ICE プロトコルで定義されている。

  送受信の文脈に沿わないメッセージが届いた場合、BadState エラーメッセージを出す。

  以下の状態遷移表には、クライアントとセッション・マネージャ双方の全ての動作が記載されている。(訳註：そうでもない。)

  一つのプロパティが保持する値(values)は全て、一個の LISTofARRAY8(ARRAY8 の配列)に格納される。プロパティの型(type)が「CARD8」であれば、値を格納する LISTofARRAY8 は一個の ARRAY8 から成り、その ARRAY8 の長さは1バイトである。そして、この1バイトに CARD8 型で表される値が入る。プロパティの型が ARRAY8 であれば、LISTofARRAY8 はただ一つの ARRAY8 から成り、そこに値が格納される。

  クライアントがセッション・マネージャに接続する度に、必要なプロパティを設定しなければならない。プロパティの設定は、クライアントが RegisterClient を送信してから、同者が SaveYourselfDone を送信するまでの間に行われなければならない。この間を外した場合のセッション・マネージャの挙動は定義しない。

  クライアントは標準で用意されていないプロパティも設定し、取得し、削除することができる。作成したプロパティの寿命を次のセッションまで延ばすことはできない。

  * 外部の保管場所(例えば状態ファイル)に記録されている状態情報がある場合、必須となる。