図1. Gikot のアーキテクチャ
正確には Gikot はアプリケーションではありません。 Gikot をひとことで表現すれば
ASCII Arts 達にアニメーションをさせるためのプラットフォームということになるでしょうか。
もともとは、デスクトップ上に置いた ASCII Art (以下AA) 達に 何かアニメーションさせるソフトをつくりたいな、と思ったことが きっかけでした。けれども決まったアニメーションをさせるだけでは 面白くないし、かといって Flash のようなオーサリングソフトを 作るのは大変です。第一それらは UNIX 的ではありません。 せっかくアニメーションをさせるなら、それらを他の用途 (時計など) と 組み合わせたり、別のプロセスから呼び出したりして、有機的に 統合しなければ面白味がないでしょう。 そこで、簡単に組めるスクリプト言語をつかって、 手軽にアニメーションが実現できるような環境を作ろうと思ったのです。 それが Gikot の基本コンセプトです。
はっきりとはわかりません。ひどいことに作者自身でさえ Gikot を 何に使っていいのかよくわかっていないんです。 いまのところヘルプエージェントなどいくつかの 応用らしきものを考えてはいますが、 できるかどうかはなんとも言えません。またできたところで、 どれくらい需要があるのかもわかりません。 ただの 2ちゃんねらー用マスコットで終わるという可能性も十分あり得ます。
正直なところ、Gikot をただのアプリケーションとして使っても さほど面白くはないでしょう。むしろ Gikot は何かを「作る」という 行為自体を楽しむ人のためにつくりました。 似たような試みとして、Python を使って 3D グラフィックスを手軽に動かす Alice Project というのがあります。 これは完成したグラフィックスの品質よりも、むしろ手軽に 動かすというプログラミングの楽しみや教育に重点が 置かれています。それなら 2ちゃんねるの AA を題材にしてプログラミングを 楽しむという環境があってもいいと思ったのです。
エージェント同士の (ネットワーク透過な) 通信がサポートされれば、 もっと別のアイデアを形にする手助けにはなるかもしれません -- でもそれがなんであるか、はっきりとしたビジョンはありません。 「こういうことに使いたい」という意見があれば教えてください。
Gikot システムはおもに 2つの種類のプログラムからなっています:
Gikot サーバは ASCII Art 達が動きまわるための仮想世界を
提供し、それを実際の X ディスプレイ上に反映させるプログラムです。
これはクライアントからの要求を受けて
画面上の AA キャラクタ達 (Gikot では「エージェント (Agent)」と呼ばれる)
を管理します。配布パッケージの中では
worldserver および xgikot がこれに相当します。
もうひとつのプログラムは Gikot クライアントで、
これは Gikot サーバに指令を送って実際のアニメーションを制御するものです。
X11 を知っている方なら、これらは X サーバおよびクライアントと
同じ関係だといえばわかってもらえるでしょう。
gbiff や gclock がこれに相当します。
Gikot はクライアント-サーバ間の通信プロトコルとして CORBA を使っています。画面上に表示される独立した (X 的に別々のトップレベルウインドウをもつ) エージェントは、 それぞれが Gikot サーバ内で一個の CORBA オブジェクトとして 表されます。Gikot クライアントはこれらのオブジェクトに対して 独立にメソッドを呼びだすことができます。
現在、Gikot はサーバ・クライアントともに Python と ORBit を 使って書かれています (さらに Gikot サーバは ORB を担当する Python プログラム worldserver と X11 の表示を担当する C プログラム xgikot に分かれています)。 しかし CORBA は言語に依存しないプロトコルであるため、 これとは別の言語を使ってクライアントを実装することも可能です (Gikotパッケージ中の IDL ファイルを見てください)。 また、CORBA では IIOP を使うことにより ネットワーク経由でもエージェントを制御することができます。
CORBA は 分散オブジェクト指向プログラミングを実現するための枠組みのひとつです。 CORBA はようするにリモートプロシージャ呼び出し (RPC) の発展形です。 CORBA を使うと、異なるプロセスのオブジェクトに対して (たとえそのプロセスがネットワーク上の別のホストで動いていても) メッセージを送ることができます。
最初のきっかけは、Gikot をつくったさいに、 エージェントをいろいろなプロセスから遠隔操作させたいと思ったことでした。 そのためには、エージェントに外部から なんらかのコマンドを送ってやる必要があります。伝統的な方法では、 UNIX の IPC を使うか、TCP/IP を使うのが一般的です。しかし、 このためには独自のプロトコルをゼロから設計しなければいけないし、 セッション管理なども厄介です。
Gikot では、ひとつのエージェントがひとつの CORBA オブジェクトに なっており、これらのオブジェクトは Gikot サーバで管理されています。 アニメーションをおこなう Gikot クライアントは、このサーバと 通信して各エージェントへの参照 (IOR) を取得したのち、コマンドを 送ることができます。また、CORBA は IIOP と呼ばれる 通信プロトコルを使うことができ、これは TCP/IP 経由で ネットワーク透過な (オブジェクトが異なるホスト上にあっても意識せずに使える) メソッド呼び出しを可能にします。
作者はまえまえから CORBA には興味がありましたが、 実際に使ってみる機会はありませんでした。Gikot は CORBA の 勉強がてらこしらえたものです。多くの技術がそうであるように、 CORBA もまた実際に使ってみることで理解がずっと容易になる技術の ひとつです。Gikot では CORBA オブジェクトが実際の画面上の オブジェクトと 1対1で対応しています。そういった意味では、 これは CORBA を勉強する人の教材にもなるかもしれません。 また、現在はまだサポートしていませんが、エージェント間の 通信ができるようになれば並列分散プログラミングの演習にもなり得ます。 アニメーションというのは結果が見えやすいので、 並列プログラミングの課題としては適切でしょう。
IOR: …" ではじまる 200バイト程度の文字列です。
ここには通信に使うプロトコルや、ネットワーク上のサーバの位置などの
情報が格納されています。Gikot では、クライアントは
エージェントにアクセスするのにまず仮想世界全体をあらわす
オブジェクト (GWorld オブジェクト) への IOR を入手することが必要です。
ふつうこれは、/tmp/gikot-ior というファイルに
格納されています。ただし当然これは同一のホストからしか見えないので、
ネットワーク経由でクライアントを使う場合は、何らかの方法で
リモートホストの IOR を取得する必要があります。
単に Python が好きだから。また、Orbit-Python が非常に簡単に 使える CORBA とのインターフェイスだったからということもあります。 また X11版「何か。」である ninix が Python を使っていたから ということもあります。とくに技術的に参考にしたわけではないのですが、 Python にはこの手の可能性もあるということを示した点で ninix は称賛に値すると思います。
Gikot クライアントは、起動時に GWorld オブジェクトへの
IOR をオプションとして取ることができます
(デフォルトではこれは /tmp/gikot-ior というファイルに
格納されていると想定しています)。これを変更すれば
ネットワーク上のエージェントを操作することが可能です。
まず、~/.orbitrc というファイルを作り、
以下のような内容のテキストを追加します:
ORBIIOPIPv4=1
この後 Gikot サーバ worldserver を起動すると、
サーバは IIOP を使用するようになり、IIOP 用のポートが
bind されます。このさい --ior オプションに
ファイル名を指定すると IOR を /tmp/gikot-ior
以外のファイルに出力できるので (ファイル名として - を
指定すると標準出力)、これを何らかの方法でクライアント側のホストに
送ってください。
クライアント側では、Gikot クライアントを起動するときに
入手した IOR ファイルへのパスを --ior オプションに
与えます (IOR 文字列をそのまま与えることもできます)。
これでクライアントは指定された IOR のホストにある
エージェントを動かします。リモートホストに IOR を渡すための
手軽な方法はまだ存在しません。これは今後の課題です。
セキュリティ上の注意: IIOP は、不特定番号のポートを bind します。 エージェントには IOR の情報がなければアクセスできないはずなので、 おそらく IOR さえ他人に漏れなければこのポートが濫用されることは ないでしょう (ただし、ORBit のセキュリティがどれほどのものかは不明です)。 IIOP が bind するポートを固定できれば SSH のポート転送などを 使って暗号化する手もあるでしょうが、 いまのところ IIOP が使うポート番号を指定することはできないようです (なんらかの原因により ORBit の ORBIPv4PORT オプションが作動しない)。
ImportError: No module named Gikot
IDLPATH が正しくセットされていないのが
原因です。
ImportError: No module named ...
PYTHONPATH が正しくセットされていないのが
原因です。
worldserver: set the environment GIKOT_DIR.
PYTHONPATH が正しくセットされていません。
Gikot.InternalError: User exception with no menbers
$GIKOT_DIR/lib/xgikot/xgikot を実行しようとします。
IOError: [Errno 13] Permission denied: '/tmp/gikot-ior'
--ior オプションを
使って、別の場所に IOR ファイルを作ってください。
ImportError: No module named Gikot
IDLPATH が正しくセットされていないのが
原因です。
ImportError: No module named ...
PYTHONPATH が正しくセットされていないのが
原因です。
IOError: [Errno 2] No such file or directory: '/tmp/gikot-ior' またはIOError: [Errno 13] Permission denied: '/tmp/gikot-ior'CORBA.COMM_FAILURE: Minor: 0, Completed: CORBA_COMPLETED_NO.
PYTHONPATH が正しくセットされていないのが
原因です。
Gikot はその性質上、ウインドウのタイプを特殊な形
(OverrideRedirect) にしています。
これは一部のウインドウマネージャによっては正しく扱えないことがあります。
そのようなときは worldserver の --windowmode を
変えてみてください。
(ここらへんについてはまだ別の環境でのテストが十分でないので 要改訂)