fml-devel とも呼ばれている &fmldevel; プロジェクトは、 &fml4; の再構想(refactoring)とその実装(例)の構築 を行なっています。 http://www.fml.org/software/fml-devel/ は将来の fml-current についてのデザインや実装例を紹介しています。 現状の fml-devel はアイデアを実装し、運用テストするための fml 8.0 のア ルファ版です。ですが、すでに動く実装例をダウンロードできますし、fml 1.2 相当ないしはそれ以上の機能を使うこともできます。しかしながら、変数 名もアーキテクチャアも本決まりではないので、将来変わる可能性があります。 でも、概ね固まったと思う。 自分がふだん使うには全然困らないのですが、&fml4; との互換性をいいだす と、まだ多くの機能が実装されていないといえまそう。これは、デザインを最 初から考え直すに当たり、アイデアや意見を募集するためにまだまだ原型にと どまっているためでもあります。 ものによっては &fmldevel; 用に作られたモジュールを &fml4; へ輸入/輸出 することも検討しています。IPv6 はすでに輸出されました。たとえば 4.0 で も独立性の高い mead (エラーメール解析プログラム)などはその良い例だろう し、新機能を提供するモジュールなども再輸入(輸出)可能なものは順次マージ していきます。 これらのマージおよび 4.0 自体のコードの保守をしつつ 4.0 および &fmldevel; は 並行開発されていく予定です。 そのため 4.0 系は stable に近い current という位置付けになります。 そして 4.0 の bug fix は 4.0.x (4.0.1 4.0.2 …)としてまとめられリリー スれていく予定です。 逆に &fmldevel; は本当の開発用のコード( fml-current )ということになります。 設定ファイルとメニュープログラムの負荷を少なくしたい 全部 perl module 形式 (要 &fmldevel;04 以降) CUI (makefml) インターフェイスおよび CGI インターフェイス これは従来通りのもの。 ただしより統合化され、 よりメニューなどが書きやすいものであるように (実装者が楽できる設定ファイル形式がのぞましい et.al.) 乖離層 バージョンアップ を簡単にできるように CPAN モジュール使いまくり (ただし、できるだけ直接使うより、 一層被せておくほうがよい) 3rd party 用ディレクトリ 統一化されたメンバーリストなどへのアクセスをできるだけ抽象化する。 ファイル (実装済み) /etc/group (実装済み) NIS (実装済み) SQL (プロトタイプは実装済み) LDAP 実際には効率の問題もあり、 あらゆる抽象化は重たくなってしまう。 しかし少々重くなっても実装しよう。 IPv4/IPv6 ready (実装済み) status 項目 詳細 done. ライセンス ライセンスを Perl 準拠へ変更する イメージ/モティーフ &fml4; から &fmldevel; へは、 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, ...