POT Prototype Systemの実装(2) など1
伊戸川暁2
今日は主に、
自分がどういう勘違いをしていたことに気づいたかについて話そうと思います。
1999年8月27日、かのXanaduのソースが部分的ながら公開された
ので(参考資料1)、取ってきて[1]少しいじってみた。
当初筆者は、
- 独自プロトコルにこだわりすぎているようにも見える、とか
- デモがついていたようだが、networkにつなぐデモをしてほしかった
のレベルで批評しようと思ったのだが、
きちんと動かないようなので少し中身を覗いてみたところ、
「構想40年の末に公開」したはずのソースの
あまりの完成度の低さに目を覆ってしまったのだった。例えば、
- まともなconfig fileがない
- 絶対パスがハードコーディングされている
- もちろんdocumentationも適当
などなど。
ちなみに、最もひどいと思った1行は、
system("cat /usr3/xu/requests.j");
である3。
ひどい感想になるが、
どうして世間でXanaduがあまりまともに扱われないのか、少し分かった気がした。
そもそもなぜXanaduのソースなどをチェックしようと思ったかだが、
それは、目的が比較的似ているからである。
- 電子情報の最終的かつ恒久的な保管場所
- グローバルかつ恒久的な命名体系
- 著作権管理
- ハイパーテキスト作成支援(自動的リンク作成とか)
- ストレージのレベルまで踏み入った管理
- 全リソースの一元的取扱い
- 管理計画を明示できる
- むしろ全体的枠組を提供(要素技術はあるものを利用する)
現在作成したコードの分量は1300行程度
4。
最近したことは:
- User Client/Serverモドキ(図2中の破線Cの辺りに相当)の製作
- プロトコル4及び5(図2参照)の製作
しかし上記作業中、以下のようなことどもに次々と気づき、
相当部分がナンセンスであると分かったところで本日の発表を迎えた。
今日の本題はむしろここです。
なんだか当たり前のことばかり言っているようですが、
本人にとっては新鮮な発見だったので勘弁して下さい。
文書の姿は、「層」ではなく、「層の間」に対応する(図1)。
層同士が「文書」をやりとりするのだと考えれば当然そういうことになる。
層の中にある「文書」は、バイト列というよりはむしろ
Objectとして存在しており、それが層の上面と下面とで
異なった表現を取ると考えた方がよい。
図1:
層と文書の対応の正誤
![[図1]](990914_f1.gif)
|
実装で試行錯誤中、層の切り分けにも仕様変更が生じた
(図2を参照)。
図中の矢印は情報(=文書)のやりとりがある、すなわち
プロトコルが存在することを示し、破線は、その両側のやりとりが
クライアント/サーバを介することを表している。
図:
階層構造図(1999年9月14日現在)
![[図2]](990914_f2.gif)
|
前回の見本xml(参考資料2)は、
図2の番号でいえば「4」でやりとりされるべき文書を考えていたものの、
- システム全体を通じて用いられるXMLの形式が一通りでは済まないこと
- クライアント/サーバが複数種類存在すべきこと
の両者によく気づいていなかったために、中途半端なものになってしまった。
従って、各箇所のプロトコル用の「文書」の定義を決めなければならないのだが、
現在策定中。
- 各部分のプロトコルの定義及び実装
- 最終的にはtest caseとしての協力文書募集
5
- 1
-
roger@xanadu.com: Udanax Green, http://www.udanax.com/green/.
- ... など1
- KTYYゼミ発表資料
- ...伊戸川暁2
- 川合研M2
- ...
である3
- おまけに配布物中には、`requests.j'という名前の
ファイルが全く存在しない。
- ...
現在作成したコードの分量は1300行程度4
- 思いついた順番に、極めて場当たり的に開発しています。
- ... caseとしての協力文書募集5
- 当初はこの発表で、ゼミとかの資料をPOTに入れたい旨
皆様にご協力をお願いしようと思っていたのだが、
発表に至る考察の結果、その予定は遠のいてしまった。
ITOGAWA Akira
1999年11月10日