IO へのアダプター層 (IO::Adapter クラス)
IO::Adapter の概要
&fmldevel; でのメンバーリストの読み書き、
例えばアドレスの登録/削除、は
IO::Adapter という抽象クラスを通じて行ないます。
例えば次のように使います。
use IO::Adapter;
$obj = new IO::Adapter $map, $map_params;
$obj->open || croak("cannot open $map");
while ($x = $obj->get_next_key()) { ... }
$obj->close;
$map は次のようなものが使えます。
file:/var/spool/ml/elena/actives
unix.group:root
nis.group:root
mysql:id
postgresql:id (未実装)
ldap:id (未実装)
file: は通常のファイルです。
unix.group:root は /etc/group の root のエントリにあるユーザのリストを、
nis.group:root は NIS の root のエントリにあるユーザのリストです。
mysql:id は MySQL へのアクセスです。
mysql:id で指定されたパラメータを用います。
このパラメータは new() を実行する際に別途与える必要があります。
メソッド
IO::Adapter の提供する公式なメソッドは次の通りです。
new()
open()
close()
get_next_key()
add(KEY)
delete(KEY)
getpos()
setpos(NUM)
eof()
touch()
find(REGEXP, $args)
です。
KEY はデータベースのプライマリキーで、
通常メールアドレスです。
REGEXP は正規表現ですが、たいていはメールアドレスです。
多くのマップを同じように扱うために、
メソッドは極力最小限にものに限定する必要があります。
最低限のメソッド群の定義は実際に実装してみる実験を通じて選ばれました。
そして、むしろファイルより SQL との IO を想定しつつ、選びました。
そのため、&fml4; のファイルを前提にした様々な処理にくらべ、
やや不自由に思えるでしょうが、そうしないとうまく抽象化ができません。
&fmldevel; で必要なメソッドの型
get_next_key() のように引数なしか STR を引数にして STR を返り値にする
ものが多いです。これはファイルの一覧を見るとか、特定のアドレスに対する
何かの値を取り寄せるとかいう操作でよく使われるためです。
しかし、特定のアドレスに対する値が組になっているものがあります。
これは
KEY_STR => [
VALUE_STR_1
VALUE_STR_2
VALUE_STR_3
]
のようなデータ構造が返ってくることを期待する場合です。
&fml4; の actives はメールアドレスに対していくつかのオプションの値を記
述するので、こういったデータ構造と考えられます。
例
rudo@nuinui.net s=skip m=xxx.yyy.z # commnet
rudo@nuinui.net => [
s=skip
m=xxx.yyy.z
# comment
]
まとめると引数はないか STR なので STR とひとまとめにしても良いです。
一方、返り値は STR か ARRAY_REF になります。
引数 返り値
---------------------------------------
なし => STR
STR => STR
なし => [STR, STR, ... ]
STR => [STR, STR, ... ]
file マップ
『file:ファイル名』もしくは単なる『ファイル名』は
ごく普通のテキストファイルへの IO を抽象化したものです。
unixgroup マップ
/etc/group を抽象化します。
当然 READ ONLY です。
/etc/group の
wheel:*:0:root,rudo,kenken
は IO::Adapter では unixgroup:wheel としてアクセスできます。
$obj = new IO::Adapter "unixgroup:wheel";
というオブジェクトに対し get_next_key() すると
グループのメンバーが順に返されます。
つまり 3 行のファイルを読みだすものとして、
root
rudo
kenken
のようなファイルとみなされます。
NIS マップ
/etc/group とほぼ同様ですが、ソースが
NIS/YP から group にあたるものを引っ張ってくるところだけが異なります。
MySQL マップ
&fmldevel; の設定では .cf の中にSQL の設定を書いておきたいと思います。
つまり一つの cf ファイルにいろいろ書けるようにしておきたい。
そこで、[mysql:members] (から終りまで、もしくは次の =head 文まで)の
ブロックで、マップのタイプと識別子を表現しています。
config.cf の例
member_maps = mysql:members
recipient_maps = mysql:recipients
[mysql:members]
sql_server = localhost
sql_user = fml
sql_password = uja
sql_database = fml
sql_table = ml
sql_find = select * from ...
...
IO::Adapter は
new IO::Adapter "mysql:members", $config;
のように呼び出します。
この $config は次のようなハッシュ・リファレンスになっていることが
期待されています。
$config => {
[mysql:members] => {
sql_sever => localhost
...
}
}
FML::Config は .cf から上のようなハッシュを構成します。
よって IO::Adapter の new() の際には、
FML::Config のオブジェクトを引数で渡せば OK です。