&fml8; プロジェクト(初期コードネーム fml-devel) は、 &fml4; の再構想(refactoring)です。 &fml8; は、何年ものあいだ安定した試験運用を続けています。 変数名もアーキテクチャアも、おおむね固まったと思います。 自分が使うには全然困らないのですが、 &fml4; との互換性は不十分かもしれません。 &fml4; の全ての機能を実装する必要があるとは思えませんが、 &fml4; の対応機能は、すでにかなりの部分が &fml8; にあります。 ものによっては &fml8; 用に作られたモジュールを &fml4; へ輸入/輸出しています。 IPv6 は、すでに輸出されました。 たとえば 4.0 でも独立性の高い mead (エラーメール解析プログラム)などは輸出可能な例でしょう。 これらのマージおよび 4.0 自体のコードの保守をしつつ 4.0 および &fml8; は並行開発されていく予定です。 そのため 4.0 系は stable に近い current という位置付けになります。 そして 4.0 の bug fix は 4.0.x (4.0.1 4.0.2 …)としてまとめられ、 リリースされていく予定です。 逆に &fml8; は本当の開発用のコード( fml-current )ということになります。 設定ファイルとメニュープログラムの負荷を少なくしたい すべて perl モジュール形式 (要 perl 5.00504 以降) CUI (makefml) インターフェイスおよび CGI インターフェイス これは従来どおりのもの。 ただしより統合化され、 よりメニューなどが書きやすいものであるように (実装者が楽できる設定ファイル形式がのぞましい et.al.) 乖離層 バージョンアップ を簡単にできるように できるだけ CPAN モジュールを使う (ただし、できるだけ直接使うより、 一層かぶせておくほうがよい) 3rd party 用ディレクトリ 統一化されたメンバーリストなどへのアクセスをできるだけ抽象化する ファイル (実装済み) /etc/group (実装済み) NIS (実装済み) SQL (MySQL、PostgreSQL 実装済み) LDAP 実際には効率の問題もあり、 あらゆる抽象化は重たくなってしまう。 しかし少々重くなっても実装しよう。 IPv4/IPv6 ready (実装済み) status 項目 詳細 done. ライセンス ライセンスを Perl 準拠へ変更する done. イメージ/モティーフ &fml4; から &fml8; へは、 sendmail から postfix への移行のようなイメージで。 最低限の config.ph コンバータは用意する。 done. メインプログラムの wrapper (乖離層)。 バージョン管理やデバッグを簡単にするための乖離層 done. 再利用性(自主開発はできるだけ避ける) 可能な限りあらゆる CPAN モジュールなどを使う。 そして利用する場合には乖離層を設けること。 たとえば ”FML::モジュール → 乖離層 → CPAN/モジュール” のように。 done. 設定ファイルの形式は cf と config.ph を統合化したようなもので、 配列を表現できる形式とする。 メニュープログラムが楽になるフォーマットにしたい。 原則として”設定ファイル”という名のものは どれも同じフォーマットとする。 変数の命名規則の規格化 ”USE_ほえ”および”ほえ_TYPE”形式か？ また、NOT_USE などは禁止する( default_config に書くこと)。 attribute にあたるものが 群れになってしまうのはしょうがない。 しかし、 配列表現が可能なため、 現在の ifdef の群れで表現するようなことが少なくなるはず。 関数名ルールの統一 main:: スペースに出てくるものは従来通り X11 風準拠に。 メソッドは他のモジュールにあるようなそれっぽい小文字の名前をつける。 lisp 的要素を廃止する。 参考文献 Perl Cookbook として、 そこにあるようなシンタックス風を推奨する？ 例: メソッドなら is_member() で、大域関数なら ”MemberP() -> IsMember()” done. (でも lmtp を実装してない;-) queue manager 再送処理のため (e.g. smtpfeed ) done. tools BSD make を使わない。 C 言語ではないので、autoconf は特には必要ないと思う。 しかしながら configure という名前のスクリプトを（フェイクでも） 用意することはよいことかもしれない。 (と、最初はいっていたけど、結局つかってます:-) そのスクリプトは、たとえば IPv6 ready か否かを決めるために使われるだろう( 現在の実装では使ってはいない、IPv6 は常に挑戦してみる )。 アーキテクトでも、デベロッパーに偏ってもいけない。 抽象化に萌過ぎても、オブジェクト指向分析に燃え過ぎてもいけない。 中庸であり、一カ月単位でフィードバックしながら プロジェクトの計画とコードレビューを行なうこと。 日取り 内容 最初の 4〜5日 計画を練り直す。 リリースエンジニアリングプロセス中の 20 ％程度はこの計画に費やすこと 2〜3 週間 コードを書く 最終週 ドキュメントを見直す、およびコードレビュー 月の切れ目 まぁまぁ大丈夫ぽい snapshot を出してみる。 alpha-0, alpha-1, alpha-2, ...