Res有難う御座います。
本年もよろしくお願いします。（私用でしばらくOFF-Lineになっていました）

私としては、中規模の技術系のプロジェクトで使えるHyperCardのようなもの
が欲しいのです。　(1)200人程度の人間が　(2)400GB程度のドキュメントを
(3)高頻度（暗黙に・無意識に）に検索　したいと思っています。またその場合には、
(4)検索エンジンとユーザーインターフェースの分離
が必要と思います。というのは、検索要求　→　検索式　というのは
かなり高度でかつユーザー固有の癖のある、超高級な仮名漢字変換
のようなものだと思うからです。従って、
(5)検索エンジンの入力は、正規表現+制御＝プログラム言語としたい
のです。（だって、データと手順が分離できるとは思えないし、かつ
複合した単語の検索は、内部的には複数の処理に分解されて、暗黙の
(プログラムに組み込まれた）手順が走るのだから、その手順自体が気に入らない
ことや拡張性を考慮すれば、内部のそういった手順は、別のユニットとして外へ出したい
訳で、その場合は手順を指示する方法が必要になる）
(6)その手順（言語）を生成するフロントエンドユニット（それ相応のルールベースを持
つ）
は、別途準備します。その場合(7)再帰的に、又は分散してこのシステム自体を使う
ことももちろん出来るでしょう。

以上のようなことを考えれば、
　(8)外部モジュールになってしまうけど、言語は組み込みやすいからtcl
でしょうか？　又、高頻度に多人数が検索する場合には、「ワーキングセット」
の問題が大きい事、了解しました。特に技術文書は、似た単語の組合せが多いので、
多数のワーキングセットがインデックス全体と似た大きさになるでしょうし、
最大値も決めにくい問題です。ですから、
　(9)従来のインデックスの他に、文書毎にソートした第２のインデックスを用意し
　(10)ワーキングセットを使わないで、一つずつ最後まで検索する
　(11)検索でヒットしたら、１件ずつ回線経由でクライアントへたれ流す
みたいな動きを考えています。最終的には分散処理もしたいのですが、いずれにしても
ワーキングセットのようなゴミ情報をそのまま回線に載せるのは量からいっても
迷惑なので、えいやっとインデックスを倍にした方が簡単な気がします。
（最近は１TBくらいのDISKはいくらもしないので、ワーキングセットのピーク対応に
苦慮するよりははるかに簡単だと思う・・）

また、文書の入力に関しては、印刷される事を前提とした文書であれば、段落とか
改行とか、紙の上の位置、文字飾りなども、検索対象として必要です。
pdfを読み込んで、そういった情報を制御文字として付加したTextを出して、それを
使うとか、htmlに変換してとか、夢が広がります。

・・・こういう事を書いていると、なんだか自分で作ってみたくなりますね。

　　高橋保彦

私は昔、プロキシとしてDeleGateを使っておりました。久しぶりに蛙の顔をみて
なんだか懐かしい思いがしています。（当時は回線事情が悪く、よくタイムアウト
で蛙君が出てきた）