-180-
話題の数に合わせて会議室をいくらでも増やすと、どこに目的の会議室がある かわからなくなる確率が高くなる。例えば会議室が400個あって、この中の14番と 22番と115番と332番がゲームの話題だとする。このことを知るために、利用者は 何をすればよいか。全会議室のタイトルを見て判断する? 勘弁してほしい。400 個のタイトルから目的のものを選択するのは無茶だし、常にタイトルが内容を表 しているとも限らない。
このような場合にどうやって整理するかは考えるまでもない。既にUNIX の木構 造のディレクトリは相当昔からこの構造を実現しているし、MSDOSでさえディレク トリは木構造であるし、そう言われてみれば NIFTY-Serve のフォーラム構成自体 がすでにそうなっているのである。２百数十のフォーラムを同じ階層に並べない のは、似たカテゴリーのフォーラムをまとめようとした結果と信じたい。(まさか 1つのメニューに割り当て可能なフォーラムの数の制限があるなんてことは、ない と思いたいのだが…) (*1)
さて、部屋を集めたものを何と呼ぶかだが。便宜的に「フロア」と呼んでおく。 なお、私としては「電子会議」「会議室」という名称がそもそもあまりよいとは 思っていないので、「フロア」というのもいまいちであると思うのだが。
仮にゲームのフロアというものが存在し、さらにその下に14、22、115、332番 の会議室があれば、利用者は「ゲームのフロア」を探すだけで済むわけだ。
同じことを FPROG でやってみた。まずこれが7/3現在の状況である。
> 番号 発言 (未読) 最新 会議室名 > 1 14 ( 0) 07/01 ＡＧＯＲＡ (4) > 2 141 ( 0) 06/28 書評 (1) > 3 339 ( 0) 07/03 ＶＯＰ (9) > 4 140 ( 0) 05/20 ソフトウェア無作法 (2) > 5 225 ( 0) 03/17 BPL.EXE 特集 (1) > 7 73 ( 0) 07/03 はてなプロジェクト (2 Q&A の部屋) > 8 399 ( 0) 04/28 ＳＥＣＬＵＢ (1) > 9 15 ( 0) 06/28 ハンドブック編纂室 (2) > 10 32 ( 0) 06/27 格言の部屋 (2) > 11 21 ( 0) 06/28 テーマ提案専用会議室 > 13 31 ( 1) 07/03 32日ステージ (38 ＳＥの定義) > 14 10 ( 0) 07/03 32日ステージ (39 わたしの出会った蟲さん) > 15 1 ( 0) 06/20 32日ステージ (40 準備中) > 16 137 ( 4) 07/03 FPROG 専用通信ソフト企画会議 > 18 60 ( 13) 07/03 ROM墓場からの声 (7月VOL.1 @~) > 19 512 ( 0) 06/28 ROM墓場からの声 (6月VOL.1 @~) > 20 123 ( 0) 07/01 ROM墓場からの声 (6月VOL.2 @~@~)方針はどうしようか。UNIXが階層ディレクトリを実現可能といっても、ホーム ディレクトリに全てのファイルを作る人もいるかもしれない。要はまとめるセン スの問題なのである。ここでは、フリートークを一番上の階層にすることにしよ う。従って、ＡＧＯＲＡ、ＶＯＰ、ＳＥＣＬＵＢは一番上に置く。細かい話題毎 の会議がいくつかあるが、それを一つ下の階層のテーマ別会議に分類する。32日 ステージは短期会議という意味で、分けておく。すると、FPROG の電子会議トッ プメニューは、こうなる。
> 番号 発言 (未読) 最新 会議室名 > 1 14 ( 0) 07/01 ＡＧＯＲＡ (4) > 2 339 ( 0) 07/03 ＶＯＰ (9) > 3 73 ( 0) 07/03 はてなプロジェクト (2 Q&A の部屋) > 4 399 ( 0) 04/28 ＳＥＣＬＵＢ (1) > 5 690 ( 4) 07/03 テーマ別会議 > 6 63 ( 1) 07/03 32日ステージ > 7 695 ( 13) 07/03 ROM墓場からの声ここで５を選ぶと、こういうメニューに移動する。
> −フロア 5 テーマ別会議 発言数 :690 未読 :4− > 番号 発言 (未読) 最新 会議室名 > 8 141 ( 0) 06/28 書評 (1) > 9 140 ( 0) 05/20 ソフトウェア無作法 (2) > 10 225 ( 0) 03/17 BPL.EXE 特集 (1) > 11 15 ( 0) 06/28 ハンドブック編纂室 (2) > 12 32 ( 0) 06/27 格言の部屋 (2) > 13 137 ( 4) 07/03 FPROG 専用通信ソフト企画会議2階層の木では面白くないので、「FPROG 専用通信ソフト企画会議」が、さらに 分類されているとしよう。
> −フロア 13 FPROG 専用通信ソフト企画会議 発言数 :137 未読 :4− > 番号 発言 (未読) 最新 会議室名 > 14 78 ( 1) 07/01 仕様検討会議 > 15 56 ( 1) 07/02 開発分科会 > 16 3 ( 2) 07/03 バグ報告6だと、ここ。
> −フロア 6 32日ステージ 発言数 :63 未読 :1− > 番号 発言 (未読) 最新 会議室名 > 17 21 ( 0) 06/28 テーマ提案専用会議室 > 18 31 ( 1) 07/03 32日ステージ (38 ＳＥの定義) > 19 10 ( 0) 07/03 32日ステージ (39 わたしの出会った蟲さん) > 20 1 ( 0) 06/20 32日ステージ (40 準備中)７だとどうなるか。
> −フロア 7 ROM墓場からの声 発言数 :695 未読 :13− > 番号 発言 (未読) 最新 会議室名 > 21 60 ( 13) 07/03 ROM墓場からの声 (7月VOL.1 @~) > 22 512 ( 0) 06/28 ROM墓場からの声 (6月VOL.1 @~) > 23 123 ( 0) 07/01 ROM墓場からの声 (6月VOL.2 @~@~)読む方法も考えておこう。MREAD コマンドを想定すれば、追加するルールは１ つである。「MREAD で指定された番号がフロアだった場合は、該当フロアの下に ある会議室を処理の対象とする」
例として、「電子会議」のトップメニューが表示された状態を想定する。
1 全会議室の未読発言を読む場合は?
mread で一発。何も考えなくてもよい。今まで通りである。
2 ROM 墓場だけ読みたいんですが…
という人がいるかどうか知らないが、この場合は mread room:7 でOK。
3 ROM 墓場だけ読みたくない
それなら mread room:1-6 でよい。
4 ＶＯＰと、ソフトウェア無作法と、通信ソフト会議だけ読むのは
mread room:3,9,13 だ。
重要なのは、このように分類するためには会議室数の制限があってはならない ということである。細かく分類できてこそ、木構造が生きてくる。あるとしても、 実用上問題のない数を使えるようにしたい。少なくとも100個、場合によっては 数百個は用意できるようにしなければ、「話題別に部屋を作る」という当初の目 的は達成できない。
CompuServe のスレッドという方法に比べてみよう。会議室を木構造にすること により、階層をいくらでも深くできる。フォーラムが階層化されているのと同じ ように会議室が階層化されているため、違和感がない。同一のコマンドを使って、 非常に大雑把な分類による複数の会議を読むこともでき、細かい特定のテーマの 会議だけ読むこともできる。
*
さて、このように会議室が階層化して個数の制限なく作れるようになったとし
ても、いくつか細かい問題がある。
例えば、ある会議室を作る場合に、まず会議室を作ってテーマが提案され、そ れに添って議論が始まるのではなく、別の既存会議室で何となく新しい話題が出 て、では新しく会議室を用意しましょうか、という流れになることが経験的に多 い。
この場合、新しい会議室に移動前の会議室から必要のある発言をいくつか転送 したい。実際、現状でもそうすることがある。しかし、転送されたメッセージは 2度読まされてしまう。
この無駄を回避するためには、既存メッセージからいくつかを取り出して、新 規会議室に移動するという保守用コマンドがあればよい。ポイントは、この時に、 新規会議室の未読ポインタを、旧会議室の状態に合わせるということである。
例えば、旧会議室に1、2、3、4、5という発言があり、ある人が3まで読んでい たとする。3、4に対して「新規会議室へ移動」、というコマンドを実行すると、 元会議室は1、2、5だけが残り、3、4が入った新しい会議室ができる。この会議 室は、3まで読んだことにしておくのだ。元会議室は、2まで読んだことになる。 こうすれば、これで二度読みを回避できる。我ながらよいアイデアだと思う（特 許を取っておこうか:-) )。
*
もう一つの大きな問題。会議室の数を増やすと、どの会議室で発言するのが適
当なのか判断しかねる場合が出てくる。例えばOS/2で動作するコンパイラの報告
は、OS/2の会議か、コンパイラの会議か、どちらに書くべきか。会議室に複数の
話題がごちゃまぜになった場合の一つの利点は、どこの会議室に書くか迷う必要
がないということだ。
この悩ましい問題を回避する具体的な方法に、マルチポストというものがある。 しかし、マルチポストは、あまりいい所がない。まず資源が無駄になりがちだ。 下手をすると、読者は2度読むことになるし…。もっともな理由のようだが、で は仮に資源の無駄がなく、2度読みしなくて済むようになっていれば、マルチポ ストは構わないか。構わないと思う。こういうのはクロスポストと言うのだが。
Newsgroupでいうところのクロスポストとは、見かけ上複数のgroupに投稿して いるが、実は実体は一つ、というものだ。UNIXだと、linkという仕組みを使って この機能が実現されている。では、NIFTY-Serveのフォーラムなら、どのようなユ ーザーインターフェースが用意できればよいだろうか。
例えば、まずいつも通りに発言する。次に別の会議室に移動する。ここでXSAY コマンドを実行すると、どの会議室の、どの発言と同じにすればよいかを聞いて くる。これによって、指定した発言と同じ内容の発言がそこに埋めこまれる。XRE というコマンドを使えば、既存発言のコメントとして登録することもできる、と いうのはどうだろうか。
この機能のポイントは、クロスポストされた発言の一つでも読んだら、他の会 議室で読む時にはスキップしたいという所にある。これによって、アクセス時間 も節約できるし、無駄な発言を読まずに済むのだ。この場合、次のように表示さ れるようにする。
> 123/125 SDI00344 フィンローダ OS/2で動作するコンパイラについて > ( 3) 92/07/07 21:46 > [( 7) 233 のクロスポスト]もちろん、クロスポストの場合も重複して表示するオプションも用意しておく べきだ。クロスポストという表現が分かりにくい？ ならば「( 7) 233 と同内容」 とでも表示した方がいいか。
*
さて、将来 NIFTY-Serve にこのような電子会議システムが実現されるかどうか、
と尋ねられたら、何のためらいもなく「されない」に賭ける。このシステムを作
る位ならペアレントリンクなど用意するわけがない。しかし、いつかは他のネッ
トで、木構造の電子会議は実現されるだろう。これも賭けてもいい。10年後のネ
ットにご注目ください。
COMPUTING AT CHAOS RUINS -180-
1992-07-09, NIFTY-Serve FPROG mes(3)-376
FPROG SYSOP / SDI00344 フィンローダ
(C) Phinloda 1992, 1996