このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

会議室システムについて考える

発言者:田中求之
( Date Friday, July 25, 1997 01:41:32 )


この会議室も、おかげさまでまもなく1000発言を数えようかという状況に
なりました。そこで、記念というわけではありませんが、改めてWebにおける会
議室システムについて、仕組みや運用など、色々な点について、みなさんと共
に考えてみたいと思います。

この発言(スレッド)では、もっぱら仕組みについて、つまりWebでの会議室の
在り方について、色々と考えてみたいと思います。運用については別の発言を
投稿しておきますので、そちらでよろしく。

Web(HTTP)のCGIという仕組みをベースにして会議室を構築するにあたっては、
独自のプロトコルを用いたBBSソフトやグループウェアとは異なり、色々な制約
や考慮するべき点があります。そうした制約下において、どのような会議室の
仕組みを作っていくかが、CGI(plug-in)を作る際の腕の見せ所でもあり、ある
意味で楽しみでもありますが、それだけに作る人によって様々に異なったもの
になるわけですし、またアクセスする人にとってもどれを使いやすいかと思う
かが異なるものだと思います。

とりあえず、私自身は、この会議室やEasyBBSに見られるように、1ページ=1
スレッド(発言)という単純な構成を基本として会議室を作るようにしていま
すが、これがベストだと言いきるつもりはありません。あくまでも、私にとっ
ては、これが一番好ましく思えるということにすぎません。そこで、話の種と
して、なぜこの1ページ=1スレッドという方式を選択したのかということを
中心に、EasyBBSにおける私の会議室の考え方を書いておきます。考え方という
と大げさですが、ようするに、会議室の何をもっとも重要な点だと考えたかと
いうことです。結局のところ、会議室の仕組みの違いは、この「何を一番重要
だとみなすか」ということで変わってくるものでしょうから。

…と、なにやら大げさに言ってますが(笑)、最初に1ページ=1スレッドに
しようと思ったのは、ようはCGIを作るのが簡単だからという理由です (^_^;;
FORM処理に、ページのファイルの末尾に追加する処理を追加すれば会議室にな
る、というそれがそもそものスタートです。もちろん、単にプログラムが作り
やすいだけではなく、発言とコメントが同じページにおさまることで、いつで
も簡単に話の流れを確認できること(これはあとから参加した人でも話の流れ
をすぐに追えるということにもなる)というメリットがあることから、この方
法でいこうと決めました。

とりあえず、私が1ページ=1スレッド方法を選んだのは、

1:CGIが作りやすい
2:話の流れが追いやすい
3:コメントが付けやすい(=複数のコメントを同時に見ながら書ける)

という点を評価したからです。

この方法のデメリットや問題点ももちろんあって、それについては改めて私の
考えは書きますが、皆さんはどう感じますか?

重松修 さんからのコメント
( Friday, July 25, 1997 10:26:17 )

EasyBBSは大変優れたインターフェイスだと思いますが、私はまだ改良の余地
があると思います。

私が思いつくデメリットを上げます。

(1) ファイルが大量に生成される。(といってもこれだけの情報で1000発言
だそうですが。。。。)HDDのサイズが大きい場合は、無駄な領域ができる。
また、バックアップが繁雑である。
(2) コメントチェーンが長くなると、すでに読んだデータをたらたらと転送する。
(3) 事後のデータ整形ができない。
(4) 時間順で読めない=一括ダウンロード(未独表示)などに不利。

これについて重松が拙作(まだまだできてません)でとった対応は、データを
すべてリソースフォークに格納するというものです。メリットとしては、

(1) 1会議室を1ファイルにするから、バックアップが簡単。ディスクも無駄に
なりにくい。
(2) リソースフォークであるため、外部からの不正な閲覧、コピーを防止できる。
(3) 時間順に保持できる。
(4) 事後のレイアウトの変更も楽

が思いつきます。

私は次のバージョンでは、以下のファイルフォーマットにてデータを格納しようと
思っています。

STRリソース
IDは発言番号(0〜65535)。日付,タイトル,投稿者名を保持。

TEXTリソース
IDは発言番号。書き込まれたメッセージを保持。

STR#リソース
IDはスレッド番号。コメント関係を記録。

※ 田中先生のOSAXを利用させていただいている関係で、上のような構成です。

私の目指すところのイメージはずばり、『茄子』です。

フレームを使うことになりますが、画面上部が、メッセージのタイトルを表示する部分。
下の部分がメッセージを表示する画面です。コメントの表示形式も、時間順や、コメント
チェーン、コメントチェーン追跡、すべてに対応できます。

というふうなことを考えております。

あと、新しいシリーズでは、ページの見栄えを変更できるテンプレート方式を採用して
いただけると助かります。(^^;;;

田中求之 さんからのコメント
( Friday, July 25, 1997 14:24:29 )

いくつかの論点が上がっていますが、その中で、データの保存形式という点について
コメントしておきます。

EasyBBSの場合は、とにかく管理を簡単にしたいということで、テキストファイルに
そのままデータを書き込みます。これによって、

1:サーバー管理者がページの編集を行うにあたってはエディタなどで作業ができる
2:全文検索処理など、検索を行うのが楽
3:いざとなればそのまま普通のページなる(この会議室の書庫のように)
4:他の機種にもすぐにもっていける(SJIS になってるので嫌われる/怒られる
  かもしれませんが (^_^;; )

という点が、私個人はメリットだと考えています。

もともと、なるべくテキストのデータはテキストファイルで持つべきだという考えを
私は持っていますし、何度も言うように、ページのファイルに直接追記すれば会議室
という発想ではじめていますので、こういう方法をとってます。

バックアップに関しては、インクリメンタル・バックアップを行えば、それほど手間は
かかりません。

ただ、ハードディスク上に小さなファイルがたくさんできてしまうという点は事実で
すが、私個人は、ハードディスクのコストを考えると、神経質になる必要はないと
判断してます。むしろ、ハードディスクのフラグメンテーションの方が問題かなと
思っています。

なお、不正閲覧やコピーというのはどういう事態を想定しているのでしょうか?


それと、リソースで管理する場合、システムがあらかじめ予約しているリソース番号は
アプリケーションが用いてはいけないことになっていますので、気をつけてください。
これを守らないと、思わぬトラブルを引き起こす原因になります(リソースの呼び出し方
に気をつければいいことではありますが、一応、決まりになってますので)。

この辺のことは、Inside Mac の Resource Manager に関する部分で確認して
おいてくださいね。なお、ID は short int ですから、-32767〜32767 ですよ。

田中求之 さんからのコメント
( Friday, July 25, 1997 14:34:21 )

肝心のデータの保存形式についての話ですが、個人的には、もしテキストファイル方式を
取らないのであれば、データベースで管理するというのがよいと思っています。LC475
クラスのマシンですと、さすがにサーバーと一緒にデータベースを走らせるのはきつい
ものがあるのですが、イントラネットなどでデータベース専用マシンでも確保できる
のであれば、データベースにぶち込んでいって管理するのが、特に検索の点で有利
でしょうね。

会議室に情報が蓄積されるに従って、情報の検索をどのように提供するのかという
点も大きな問題になってきます。EasyBBSの場合は、全文検索を行うようになって
ますが、処理の時間を考えるとつらいものがあるのは事実です。

このサイトのように、サーチエンジンを導入するというのも一つの解決法ですが、
日本語の扱えるサーチエンジンが(個人向けには)出ていないという状況では、
データをデータベースソフトに入れておいて、データベースに検索を行わせる
というのが、検索サービスとしては一番まともでしょうね。

田中求之 さんからのコメント
( Friday, July 25, 1997 16:44:42 )

>(リソースの呼び出し方
>に気をつければいいことではありますが、一応、決まりになってますので)

128 以下の ID を使っていると、呼び出し方うんぬんに関係なく、エラーを
引き起こす可能性がありますね。

ドキュメントなどで使用するリソースは、確か 5000 以上が安全ということ
だったと思います(システムの予約分、各アプリケーションが利用する範囲を
外すということで)。


田中求之 さんからのコメント
( Friday, July 25, 1997 16:46:29 )

>もしテキストファイル方式を
>取らないのであれば、データベースで管理するというのがよいと思っています。

期せずして、Tango を使って EasyBBS 風の会議室を構築する方法が、内田洋行の
サイトで公開されるようです。


石津@RJC さんからのコメント
( Friday, July 25, 1997 18:00:48 )

>期せずして、Tango を使って EasyBBS 風の会議室を構築する方法が、内田洋行の
>サイトで公開されるようです。

これってどこでしょう?探したけど見つからなかったです。

田中求之 さんからのコメント
( Friday, July 25, 1997 20:39:26 )

まだ公開されてないと思います。

>公開されるようです。
         ^^^^^^

一応、未来形(伝聞に基づく推量ってやつかな) (^_^;;


石津@RJC さんからのコメント
( Friday, July 25, 1997 22:01:15 )

あ、どうも失礼しました。(^_^;

Tango版EasyBBSなら私にもできるかな。
でもTangoで作ってもあんまり意味がないよーな...。(^_^;

私見ですが1トピックス1ページという考え方はとてもすっきりしていて好きです。
Perl系に多いタイトルだけスレッド表示していくのは、あんまり...。

長いページをスピーディに見せる工夫はあってもいいかもしれませんね。

田中求之 さんからのコメント
( Saturday, July 26, 1997 00:13:24 )

>長いページをスピーディに見せる工夫はあってもいいかもしれませんね。

プロトコルとしては HTTP を使うけど、会議室の閲覧などには専用のブラウザを作って
それを利用する、という方法を使うのなら、たとえば新たな書き込み分のデータだけを
一括して転送して、ユーザーサイドで展開させるという方法なども可能なのですが、
Web で会議室をやることの意義の一つに、機種依存/環境依存無く参加できるという
のがありますので、こういう専用クライアント方式は無理なんですよね。

ただ、CGI の制約から、1ページが最大で24Kいかに押さえられてますよね。
で、24Kったら、小さい画像1つ分ぐらいですから、私個人は、この転送速度
ぐらいは気にしなくてもいいのではないかと思っています。

発言/コメントを1ページずつにわけたときには、確かに必要な発言だけ読めるわけ
ですが、リンクをたどるときには、その都度、アクセスをかけるわけで、これが私
などは、けっこうじれったいんです(特に私のサイトのバックボーンの関係で co.jp
サイトにはアクセスに時間がかかりますので)。

ま、発言を分けると、削除とか差し替えといった、管理が楽になる部分もあることは
確かですし、一つの発言を起点に、複数のスレッドに別れていく(NIFTY などでは
よく見掛けますよね)といった展開も可能なので、それはそれで良いところもあります
けどね。

元永二朗 さんからのコメント
( Saturday, July 26, 1997 03:14:35 )

>私の目指すところのイメージはずばり、『茄子』です。

私が書いたヤツはコメントツリー表示、書き込み順表示に対応しているので、こ
の間試しにフレーム切ってやってみたんですけどね、イマイチっす。何故か、と
考えてみたんですが、どうやら「今読んでいる発言がインデックス中でどの発言
か、スレッドのどの辺か」ということが分からないからのようなんです。茄子R
なんかのログブラウザーだと、当たり前と言えば当たり前ですが、インデックス
中の当該発言がハイライトしますよね。HTMLではこれが出来ない。勿論動的にイ
ンデックスを生成すればFONT COLORなんかで表現できますが、発言を移る度にイ
ンデックスまでロードし直しになるので、滅茶滅茶重くなりますよね。ひょっと
するとjavaで簡単にできるのかなと今思いましたが・・。

だいぶ以前に、某日本でTangoを売っている会社の人 (^_^;; からメールで「茄子
Rみたいなの作りたいから参考にソース頂戴」って言われて差し上げたりもしま
したがその後どうなったことやら・・。

>Perl系に多いタイトルだけスレッド表示していくのは、あんまり...。

私のがまさにこれです。と言っても、今でこそPerlですが、元々はawkでした。い
や、どっちにしろ基本的にラインごとの処理が楽な言語なもんで・・
確かにデメリットや的を外したか?という面も多々あります。

>発言を分けると、削除とか差し替えといった、管理が楽になる部分もある
>ことは確かですし、

これは本当に楽です。あと、ハードディスクの無駄とお叱りを受けそうですが、
各発言とも書き込み時にすっかりHTMLに仕立てて拡張子も.htmlにしてあります。
インデックスすら処理するのは書き込み時だけで、読むときはcgiは全く動かない
ようになっています。ハードディスクとCPUとを天秤に掛け、アクティブメンバー
とROMの比率、そこから導かれる書き込みと読み出しの頻度(大げさな(^_^;;)、
さらに自分の技量で実現可能なcgiの実行速度なども考え合わせた結果、この仕様
になりました。

>一つの発言を起点に、複数のスレッドに別れていく(NIFTY などでは
>よく見掛けますよね)といった展開も可能なので

ところがですね。上記のような仕様にした結果かWebのユーザー層の特性か、はた
また雰囲気づくりが失敗しているのか、私がメンテしている場所では話題を深追
いすることがあまりないんですね。追うとしてもそれが多岐に渡ることはほとん
どなくて、つまり結局はスレッドが一直線に伸びて行く。EasyBBSは的を射た仕様
だなあと思いました。


→  こんな仕様の会議室です

田中求之 さんからのコメント
( Saturday, July 26, 1997 23:36:20 )

>インデックスすら処理するのは書き込み時だけで、読むときはcgiは全く動かない
>ようになっています。

これは確かにポイントですね。EasyBBS の場合は、アーカイブに移したもの(コメン
トを付けられない)はHTML ファイルとして単純に読めるのですが、そうでないものは
コメント欄を追加するために、かならず CGI を通して読み出す必要があるわけです。
この仕様は、AppleScript のようなマルチスレッドでは動かせない環境で CGI を
組んでいる場合に、けっこうネックになりますね。


会議室の形として NIFTY のオフライン・ブラウザーである茄子をモデルにするという
のは、元永さんの指摘する問題点などもあって、私は Web (HTTP) というプロトコル
では難しいと思っています。

もっとも、HTTP プロトコルを利用して新規発言を一気にダウンロードできるように
しておいて、それをユーザー側で茄子のログファイルに展開/追記するというソフトを
作れば、オフラインのリーダーに茄子そのものを使うことは可能でしょうけどね。



稲垣@信州 さんからのコメント
( Monday, July 28, 1997 11:31:45 )

 話の流れからそれますが、MLと共存できる会議室なんかが出来ると
嬉しいです。

 NewsとE-mailはうまく?共存できるようですが、・・。

 MLも便利ですが、スレッドごとに分けれ無いので、話をまとめにく
いのですが、使用しているハードの制限が低いので、広がりやすいで
す。(286+DOSを使った人も参加してくれています。)

 Webの会議室だと、読み書きの間接続しておかないといけないのは、
貧乏な方だには辛いと思います。また、ハードもある程度のレベルも
いりますし。

 まあ、実際に混ぜるとしたら、メイルからの発言を登録できるよう
にして、新規の発言をMLにながすのでしょうか?

 話の流れを、折ってしまいましたが、こんな会議室のシステムがあっ
たらうれしいです。



田中求之 さんからのコメント
( Monday, July 28, 1997 11:54:44 )

>MLと共存できる会議室なんかが出来ると
>嬉しいです。

共存するかしないかという問題も含めて、メーリングリストやニュースがすでにある
状況で、Web でわざわざ会議室を設けることの意味は何か、という点は考えるべき
ことであるのは確かですね。

個人的には、ML との共存は不要、というかMLはMLで完結すべきもので、過去のメール
のアーカイブとして Web を使うのはよいとしても、Web の会議室が ML と連動する
ことには疑問を感じています(仕組み自体は、やろうと思えばできることは実験済みで
この会議室に1時期メールで投稿してたこともあるんですよ (^_^;; )

言い方を変えるならば、ニュースやMLにはない、Web の会議室の特徴とはなにか
ということになりますが。



kozka さんからのコメント
( Monday, July 28, 1997 16:24:58 )

私は「1ページ=1スレッド方法」がとても見やすいと思っています。

それと「最近の発言のダイジェスト」をもっとも多く使用します。ここへくる
とまず「最近の発言のダイジェスト」を見て興味のある話題があればそれを見
ます。ダイジェストでは発言タイトルだけでなく発言内容も表示されるのが私
にとっては良いです。もし発言タイトルだけの表示なら興味の無いタイトルは
目もくれないところですが(クリックして発言を見てまたバックしてくるのが
面倒)、発言内容も表示されるおかげで興味の無い話題にもクリックなどの操
作なしに一応は目を通す事ができます。「最近 7 日間に投稿/コメントされた
発言」は使わなくなりました。

会議室システムについてまだ触れられていないのではと思う点があります。そ
れは会議室が分散して存在することによって目的の情報を探し出しにくくなっ
てしまうのでは、という点です。現在は田中さんのこの会議室が「Macでイン
ターネーットサーバ」について最も情報が集中しているのでここで情報交換を
すれば何も問題はありませんが、他の場所でも少しずつ会議室が立ち上がって
きて情報が分散されていきそうな気配を感じるのですが、、、


田中求之 さんからのコメント
( Monday, July 28, 1997 20:40:52 )

>それと「最近の発言のダイジェスト」をもっとも多く使用します。

1ページ=1スレッドの欠点は、いうまでもなく、必要な発言だけを読むことができない
(かえって面倒)という点にあります。ですから、これを補うという目的で、Recent
なり Digest という仕組み、あるいは Cookie ヘッダーによる未読のリストアップを
試していますが、それぞれ長所と短所があって、決定打にはなりませんね。このへんは
まだまだ工夫する必要があるのかもしれません。

Digest は、書き込みに <PRE> タグを使うのを前提にした会議室では組み込みやすい
のですが、そうないと少し面倒な部分がでてくるので、現在の EasyBBS のシリーズには
組み込んでいませんが、ざっと内容を見たいときには便利ではありますね。ただ、複数の
会議室が開催されている状況では、20発言という制約では使い物にならないかなとも
思っています。

田中求之 さんからのコメント
( Monday, July 28, 1997 20:56:02 )

別の話題になるのでコメントを分けました。

>会議室が分散して存在することによって目的の情報を探し出しにくくなっ
>てしまうのでは、という点です

これはある意味でインターネット自体の問題点として指摘されていることですよね。
でも、私は、これがそれほど悪いこととは思わないのですよ。

ただ、確かに不便なことはあるので、このへんは、たとえばサーチエンジンの利用で
連携を図っていくといった方法でなんとかなるのではないかと思っています。





狩野正嗣 さんからのコメント
( Tuesday, July 29, 1997 02:18:23 )

>「最近の発言のダイジェスト」

 私もこの会議室を見るときは、まずダイジェストのページにアクセスし
ています。特に頻繁に見に来る様な場合には、ダイジェストがとても便利
ですね。

>会議室が分散して存在することによって目的の情報を探し出しにくく
>なってしまう

 会議室の場合、話題に関連性のある会議室のインデックスページを作成
して、ひとつの会議室群として扱うのもいいのではないかと思います。

→  AppleScript Conferences

重松修 さんからのコメント
( Tuesday, July 29, 1997 17:26:29 )

浦島レスですが、もともと、旧来のパソコン通信的な利用を想定しているので
『不正な閲覧』というのは、URLからアクセス権のないユーザーがデータを閲覧
する、要するにCUGがCUGでなくなることがあるかも知れない、と思ったのです。

データベースに保存する、というのは、ファイルメーカーProで試しましたが、
マシンが遅いので(Centris650/68040)、どうにもこうにもいらいらしてちょっと
実用にならないと感じました。Lasso Serverだと、使えるのかな、とも思っていますが、
あれはPowerPC専用だった気がします。それに、これは、先生のおっしゃってる
そのままリダイレクトすることができなく思います。

不特定多数が、ものすごい勢いで閲覧する(ほとんど書き込まない)場合は、
現状の方式でよいのではと思いますが、パソコン通信的運用をすると、つながりが強く
なるので、たとえば、書き込みの際、発信元が特定できない、ということが
問題にもなりえます。

つまりは、掲示板か電子会議室かの違いではないでしょうか?BBSの本来の意味は
掲示板ですけど、パソコン通信のホストもBBSというのでややこしいです。(^^;;

茄子の話ですが、今いるメッセージがハイライトする処理は難しいですね。
Notes+Dominoでは、転送し直しているようです。(現在位置と表示されます)
フレームとともにJavaScriptを使えば、楽ですが、Netscape以外のブラウザ
でどうなるかわからないし、突き詰めるとNetscapeのPlug-inとともに動作
させるのが一番良いのではと思っています。思っているだけで、実現する
力はありません。(T_T)

インターフェイス的には、茄子で、機能的にはFirstClassのように、発信者
をクリックすると、プロフィールが見られたり、メールが送れたり、
同時にアクセスしているメンバーに短文が送れたりというのがあればいいなぁ
と思っています。(チャット、電報・Page)