fml5 [ fml リファクトリング プロジェクト (Refactroing Project) ]

いくつかのアイデア
status 項目 備考
ライセンス
ライセンスを Perl 準拠へ変更する
イメージ/モティーフ
fml4 から fml5 へは、sendmail から postfix への移行のようなイメージで
最低限の config.ph コンバータは用意する。
メインプログラムの wrapper (乖離層) バージョン管理やデバッグを簡単にするための乖離層
	fml.pl ---> /etc/fml/main.cf
	       ---> libexec/loader
	       ---> libexec/$VERSION/process_switch
	       ---> lib/$VERSION/モジュール
	
再利用性
自主開発はできるだけ避ける。
可能な限りあらゆる CPAN モジュールなどを使う。 また、利用する場合にも乖離層を設ける。
	FML::モジュール →  乖離層 → CPAN/モジュール
	
インターフェイス仕様
設定ファイル形式
  • cf と config.ph を統合化する
  • 配列を表現できる形式
  • メニュープログラムが楽できるフォーマットを
  • 原則として”設定ファイル”という名のものは どれも同じフォーマットとする。
変数名ルールの統一
  • USE_機能
  • 機能_TYPE
  • 機能_ATTRIBUTES

”USE_ほえ”および”ほえ_TYPE”形式か? また、NOT_USE などは禁止する( default_config に書くこと)。
attribute にあたるものが 群れになってしまうのはしょうがない。しかし、 配列表現が可能なため、現在の ifdef の群れで表現する ようなことが少なくなるはず。
関数名ルールの統一
main:: スペースに出てくるものは従来通り X11 風準拠に。 メソッドは他のモジュールにあるようなそれっぽい小文字の名前をつける。 lisp 的要素を廃止する。 参考文献 Perl Cookbook として、 そこにあるようなシンタックス風を推奨する?
例: メソッドなら is_member() で、大域関数なら
 
	MemberP() -> IsMember()
	
queue manager
再送処理のため (e.g. smtpfeed )
tools
BSD make を使わない。
C 言語ではないので、autoconf は特には必要ないと思う。 しかしながら configure という名前のスクリプトを(フェイクでも) 用意することはよいことかもしれない。 そのスクリプトは例えば IPv6 ready か否かを決めるために使われるだろう。