将来の移植性/拡張性を見すえるなら、 MLサーバの設計においても Unix における Vnode/VFS interface (vnode(9)参照) のような構造をあらかじめ導入しておくべきでしょう。
例: NetBSD の vnode 構造体。
struct vnode { ... voff_t v_size; /* size of file */ int v_numoutput; /* num pending writes */ long v_writecount; /* ref count of writers */ ... int (**v_op)(void *); /* vnode ops vector */ ... void *v_data; /* private data for fs */ };v_op の先に、 vop_open() vop_read() vop_getattr() などが定義されます。
つまり struct vnode の **v_op (vnode operation vector) にあたるものが、 IO に使われるクラスの各メソッドです。
fml8 では IO::Adapter クラスという抽象化されたインターフェイスを使います。 このクラスは、 たいていはメールアドレスの一覧という行指向のリスト型データに対する IO を抽象化したものです。
fml8 の設計上の手本となるクラスは IO::Adapter といえるでしょう。 実装もすでに完成形であり、 primitive なメソッドは何か? などについても十分考えぬかれています。
IO::Adapter クラスは
KEY => VALUEもしくは
KEY => [ VALUE, VALUE2, VALUE3 ]のいづれかの型のデータ構造を抽象化していると考えられます。 つまり、これは RDBMS の基礎理論同様の表型データ構造です。
KEY1 VALUE1-1 "" "" KEY2 VALUE2-1 VALUE2-2 VALUE2-3 KEY3 VALUE3-1 VALUE3-2 VALUE3-3 KEY4 VALUE4-1 VALUE4-2 VALUE4-3
ユーザリストを管理する上で必要最低限の基本メソッド群は、 IO::Adapter の
open() close()および、そのオブジェクトへの IO である
add(KEY, ARGV) (ARGV はクラス依存のデータ渡しのためにある引数) delete(KEY) find(KEY or REGEXP) get_next_key()があれば十分のようです。 少なくとも、ユーザ管理は、これらのメソッドだけで十分書けます。
Copyright (C) 1993-2025 Ken'ichi Fukamachi mail:< fukachan at fml.org >