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