「十年たったらソフトウエアは一から書き直せ」 そういう悟りの境地が大事だと思う今日この頃です (一撃でまとめすぎでしょうか？)。 現状の &fml8; は、 (&fml4; 完全互換ではないため 「かぎりなく Release Candidate なベータ版」というあつかいですが) 実際には何年にも渡って運用し続けている安定版です。 メーリングリスト(ＭＬ)・ドライバとしての基本機能は全て実装されています。 コマンドラインインターフェイス(CUI)は設定メニュー画面をのぞき、 すべて実装済です。 ＭＬごとに細かい設定変更をしたい場合はファイルの編集が必要ですが、 普通に運用するのであれば、&fml4; と同様に使えるはずです。 GUI も基本機能は実装済みです。 こちらも設定メニュー画面が未実装で、まだいろいろ作りこまないといけません。 なお、&fml4; と &fml8; の相違点については、 を参照して下さい。 &fml4; の細かい機能の中には &fml8; で非採用となったものもありますが、 たいていの用途は &fml8; でカバーできるはずです。 現在 &fml8; で動く機能、そして最近の TODO リストは http://www.fml.org/software/fml8/fml/doc/ja/todo/STATUS.txt を参照して下さい。 &fml8; プロジェクトは &fml4; を「1 から書き直す次世代 fml プロジェクト」です。 &fml4; と &fml8; の関係は sendmail と postfix のような関係というアナロジーが適切です。 &fml8; は &fml4; までにいたる約 10 年の経験ふまえ、 現代的観点から &fml4; の”機能”を再構想/再実装する試みです。 (1)「作者自身」が (2)「同じもの(もしくは非常に互換性の高いもの)を一から書き直す」 試みは初めてなのではないかと思います。 条件(1)(2)の片方だけであれば、今までもいろいろとありました。 とくに(2)の一番すぐれた事例が Postfix でしょう。 &fml8; には、 デザインを一から考え直すことに加え、 &fml4; の機能や変数群の整理整頓といった要素もあります。 たとえば &fml4; を使っていて気になる点の一つは 「特定のホストで、ディスクの上にメンバーファイルを書く」 というデザインです。 これは &fml4; の最初から継承されてきている基本構造です。 &fml4; 設計当時のターゲットマシンは 4.3 BSD (SONY NeWS)で、 CPU は MIPS3000 が最先端だった時代でした。 IBM 互換 PC (i386 〜 i486)が普及してきたのは、もう少し後です。 初代の ftp.fml.org (当時は phys.titech.ac.jp ドメイン)が i486 でした。 ワークステーションが 200 万円、IBM PCが 40 万円くらいした時代の話です。 もちろん当時もホームディレクトリで NFS は使っていましたが、 「ＭＬサーバを動かすならデータの保存対象はローカルディスクのみ」 という判断をしました。 まして LDAP や RDBMS なんて必要がなかったし、 分散して動かすほどマシンが手元にありません(苦笑)。 ただ、初期段階で想定外のものに対して拡張対応をするのは、 やはり、いろいろな無理があるものです (← ここは 20 年の含蓄を含んだセリフです)。 しかしながら、RDBMS との連携や冗長化構成を考えると問題があります。 「NFS の時はどうする？」 「トラブルチケットシステムと連動したい場合は？」 「SQL サーバとも連動したいですね？」 などなど… また、構造論ではなく単に自分で欲しい機能があります。 fml 自体が簡易版 bug tracking system を提供して欲しいし、 bug tracking system も検索もできるだけメールと連動していろいろして欲しい。 cvs ログとも連動して欲しい。 SPAM は隔離しろ。 最初にするべきことは 4.0 の機能とそのデザインについての再検討です。 たとえば、次のような項目が考えられます。 &fml8; へ引き継ぐべき機能は何か？ &fml8; でもっとうまく、 よりカスタマイズしやすいものに実装できないか？ すでに不要の機能は何か？ これらについての意見を募集したいと思いますが、 ばくぜんと議論してもしょうがないので、 議論の叩き台として動くものを作って動かしています。 それが &fml8; です。 http://www.fml.org/software/fml8/ ftp://ftp.fml.org/pub/fml8/ &fml4; と &fml8; は &fml8; で作られたモジュールのマージと &fml4; 自体のコードの保守をしつつ、 並行開発されていっています。 そのため 4.0 系は fml プロジェクト全体の中で、相対的に stable に近い current という位置付けになっています。 4.0 の bug fix は 4.0.x (4.0.1 4.0.2 …) としてまとめられリリースされていく予定です。 また 4.0-current は 4.0.x のためのテストケースであり、 &fml8; が本当の開発コード( fml-current )という位置付けといえます。 fml-devel -----------------------------> 8.0 ? (次世代プロジェクトの目標) ↑↓交流 1.2 〜 4.0 ------------------------------> 4.0-current | | 4.0.1 4.0.2 .... (リリース / 4.0-stable バージョン) また、&fml8; 用に作られたモジュールを &fml4; へ輸入する予定です。 たとえば 4.0 でも独立性の高い mead (エラーメール解析プログラム)や、 スレッド追跡システムは &fml8; 版で置き換え可能でしょう。 これは &fml8; の機能を 4.0 でテストをするいう意味あいでもあります。 この作業は 4.0.4 か 4.0.5 以降本格化する予定です。 言い替えると、 4.0 系列の bug fix は 4.0 で行ないますが、 新機能は、 &fml8; で開発したものをモジュール単位で 4.0 へ輸入していく形をとります。 次世代 fml の議論のためのメーリングリストを用意してあります。 登録の仕方はいつもと一緒です。 fml-devel MLへの自動登録は fml-devel-ctl@ffs.fml.org へ subscribe の後に自分の名前をローマ字で続けたフレーズをメールの"本文" (注意: メールの本文)に書いて送って下さい。 たとえば次のようになります。 To: fml-devel-ctl@ffs.fml.org subscribe Kinomoto Sakura このメールに対し、登録意志確認のメールが送り返されてきます。 そのメールに返事をしてください。 ＭＬに登録されます。 ＭＬに参加しないが、要望等を送りたいという場合、ＭＬではなく fml-request@fml.org へメールを送って下さい。 このメールは適宜 fml-devel 等に流して議論したいと思います。 他にフォワードなどされたくない場合はその旨を一筆書いておいて下さい。 github.com/fmlorg/fml8 に issue をあげるのが現代的でしょうか、 もちろん、 それでもかまいません。 &fml8; のアイデアのついて、 ご意見・御感想をお待ち しております。 端的にいえば 4.0 のここは受け継ぎたいが、 あの機能はどうでもよいとか、 あの機能はこう実装するべきだなどといった意見も募集しています。 §.terms; &list.recipes;