1999年5月24日(1999年6月2日更新)
メッセージの保管形式に関しては次のポリシーで運用する。
このポリシーの長所として思い付くものをあげてみる。
逆に短所と思われるものをあげてみる。
この短所は大容量のハードディスクが安価に手に入る現在では恐らく問題にならないでしょう。
タイムスタンプをファイル名にする理由は、ディレクトリ内のファイルリストを取得するオーバーヘッドを省略できるからである。例えばシーケンスナンバーを付けるとどうしてもディレクトリ内のファイルの最終番号を取得する必要が出て来る。特定のファイル内に最終番号を記録するという手もあるが、そのファイルの内容の更新を頻繁に行わなくてはならないし、管理情報ファイルは(ただでさえ多いので)出来るだけ増やしたくないという考えもある。また、ファイルリストの取得して最大値を探すとなると、メッセージ数が数千〜万通になると結構馬鹿にならない。そこで格納する時刻のタイムスタンプをファイル名にすると、これはそのままユニークなファイル名なのでそのまま使うことが出来る。実にシンプルである。
Java では時間の管理の1970年1月1日 00:00:00 UTC(いわゆる Epoch)を起点としたミリ秒で行っている。64ビット(long)であるため将来的にもとりあえず問題は生じない。そういうわけで、最小単位は1ミリ秒であるが、メッセージを取得する間隔がそれ以内であると問題が生じることになる。では、実際はどうかというと、筆者の環境ではあるが、LAN(10Mbps)内ではおよそ200ミリ秒、ISDN 64Kbps ではおよそ1秒であるため問題は生じないと思われる。1ミリ秒以内になるような羨ましい環境にはまず当分ならないだろうと考え、この方針で行うことにする。しかし、マシンの時間がずれていて、それを修正したため、同じタイムスタンプのファイルが既に存在する可能性もある。このときは数値をインクリメントするだけで済ませる。取得間隔が1ミリ秒以内になった場合も同じ動作で処理できるはずである。補助シーケンスナンバーなどを付けるなどで処理も出来ると思うが、それはそのような時代になったときにでも見直すことにする。
高速な動作を行うために、ディスクに対する読み書きを行うのは送受信時およびメッセージの表示時、及び起動/終了時のみとし最小限にとどめる。振り分けなどによるメッセージのディレクトリ間の移動はファイル名の変更で済むため負荷にはならない。このディスクアクセスを最小限にするためにインデックスを作成し、利用する。
インデックスにはリスト画面での表示および振り分け条件に必要なヘッダーの情報を格納し、ファイル名をキーとしたハッシュテーブルとしてメモリ上で運用する。このインデックスは起動時に読み込まれ、メッセージの保管時に追加され、終了時に変更がある場合のみ保存される。何らかの原因で異常終了した場合は、変更があったディレクトリに対してインデックスの再構築を行う。
現状で考えられる問題点としてはメモリ資源を浪費することである。1メッセージ当たり0.5Kバイトのインデックスをメモリに保持するとして、2000メッセージで1Mバイトのメモリが必要になる。メイリングリストにたくさん入っている人なら数万メッセージくらいはすぐに溜るでしょうから、多いに問題になりそうである。再考の余地あり。