りもフォーラムへ戻る
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)