りもフォーラムへ戻る

LiMo BBS システムの設計と構造

BBS システムに付いて語る前に、まず現在製作中のシステムが どういった構造になっているかを解説したいと思います。
まずは私が目指しているところの提示から行うという意味でも。
それに、ソース公開といっても置いておくだけで説明も無しでは 手を出しにくいですからね (^^;

■ 製作ポリシー

いちおう私にも「こういう物をつくるんだい」というポリシーが あって製作を開始しています。それを理解して頂くと 「なんでこんなになっとんじゃい」といった部位もナットクして いただける……、かもしれません。
・WEB 掲示板であること
あくまで HTTP を用いた WEB Browser で利用できる WEB 掲示板とします。
現在最も普及していて「インターネット」の代名詞ともなっている、 WEB Browser でアクセス出来るようにします。 このことは、一般的利用者への負担をかけないと共に、既にある WEB 掲示板と同じ概念で利用できる事を意味しています。

・特殊な環境を必要としないこと
今では誰でもがレンタルサーバーエリアを手にいれて、そこに 個人の WEB ページを設置することができます。CGI が使える レンタルサーバーも多く、WEB 掲示板を自分のサイトに設置する 事が割と容易に行える時代となりました。
そういった文脈の上での WEB 掲示板を目指します。 つまり、CGI が使えるサーバーだったらどこでもだれでも設置 出来る様にしたいと考えています。
特殊なアプリケーション環境(zopeとか)だけではなく、 データベースシステム(gdbm や dbm すら)も利用しません。 さらに言うと出来る限り標準ライブラリ以外を必要としない 作りにします。
現在は ruby で書かれています。世の CGI というとやっぱり perl が メインだと思いますが、ruby が使えるレンタルサーバーエリアも 多くなりましたのでここは一つ許容ということで……。

・記事データはテキストでストアする
既存のデータベースシステムを避ける理由の一つでもあります。
データは必ず plane text で保存することをポリシーとしています。 そうしておけばエディター一つで確認出来ますし、やろうと思えば 修正することも可能かもしれません。バックアップもコピーする だけですし、復旧作業も容易なはずです。
なにより資産でもある記事データを他のシステムに移そうと考えた際 テキストであることは優位であると考えます。元のデータベース システムがなくても、フィルターだけでデータを移行できるでしょうから。

・ruby で書く
これは個人的趣味に因ります。それだけ。
以上はシステム的なポリシーです。
設計や内容的なポリシーはまた別の機会に。

■ システムブロック図

■ データベースクラス

アーティクルデータをファイルシステムにストアしたり、 ファイルシステムから特定アーティクルを取り出したりする部位です。
アーティクルには 1 から通しのシリアルナンバーが付いていて、 その番号を指定するとアーティクルを得る事ができるといったただ それだけの働きをします。アーティクルの編集を行えるように、 指定番号のアーティクルに現在のアーティクルを上書きするという 機能も持たせました。
データベースクラスが扱うのはベタのテキストの固まりでしかありません。 データの構造や構文についてはデータを渡した上位クラスに依存します。
gdbm を使うとえらく簡素になりそうな部分ではありますが、 そこはポリシーに従うためにオリジナルなコードを書きました。

■ アーティクルクラス

掲示板の記事ひとつひとつをカプセル化します。 カプセルというよりアーティクルの要素を束ねている構造体といった 感じですが。
データベースクラスと直接のやり取りをするのがこのクラスです。 オブジェクトひとつでひとつのアーティクルを保持しますので、 100件の記事を表示する際とかはオブジェクトも100個作られます。 富豪的プログラミングスタイルな気もしますが、わかりやすさ 優先という事で。
データベースとやりとりする際は XML 的なタグ形式にまとめてやって います。本当は完全な XML にしたかったんだけどライブラリの必要性、 オーバーヘッド、文字コードの問題等からオリジナルな実装になって います。
アーティクルオブジェクトを生成して記事番号を与えると、その記事番号 のデータをデータベースから読み込んでデータをパースしオブジェクト 内に保持します。書き込みはその逆でオブジェクトにアーティクル要素 をセットして書き込み要求を出すとオブジェクトがデータベースクラスを 介してデータを書き込みます。
あとアーティクルを HTML 化して標準出力するメソッドもありますが、 これは簡易にシステムを組む際の補助で、より上のクラスが HTML 化する 事も可能です。

■ ヒエラルキークラス

アーティクル同士の繋がりをパースして構造化するのが ヒエラルキークラスです。
上位クラスからの要求に応じてアーティクルを検索し、array (束)にして 渡す役割を持ちます。 記事1個を取り出すのや、新着記事上から10個というのもヒエラルキーです。
いちいちアーティクルクラスを生成して、そこにある情報を見ていくので 実はかなり処理的に重い(＆無駄)です。ここいらへんの構造情報は 新規アーティクルの投稿があった際に一回だけ生成して後は静的に 扱うといった方法の方がスマートだと思います。ですが色々と 模索している状況である現段階では簡潔なコードを色々と 取り回して実験しまくるほうが良いと思います。
パフォーマンスはそのあとでもゆっくりと。

■ BBS 表示ページ

ユーザーがアクセスしたらアーティクルを画面に表示する CGI です。
この表示ページとヒエラルキークラスの連携構造で色々な表示体型を 持つ事になります。表示ページは 1つの掲示板に複数あることを想定 しています、新着ページ、ツリー表示、検索表示、といった感じで。
また、このページ部分を用意することで WEB browser 以外からの 掲示板アクセスが可能になります。例えば、メールで閲覧投稿とか、 携帯電話からの閲覧投稿とう方面への発展が期待できます。
様々な表示形態に対応するためにデータベースを切り放したシステム というのがコンセプトになります。(流石にネットワーク透過性は ありませんが)

■ BBS 投稿ページ

ユーザーがアーティクルを投稿するためのフォームページです。
表示ページと同じく、ユーザーとのインターフェースに応じて この部分は入れ替わることを期待します。

■ 投稿 CGI

投稿フォームからのデータを受け取る CGI です。
アーティクルオブジェクトを新規に作成してそこにフォームから 受け取ったデータを詰め込んでデータベースに書き込み要求を 出します。

Feb.02.2002 れろれろ＠ふみ(K.Kunikane)