<!--
   $FML: design.sgml,v 1.11 2004/10/06 09:07:38 fukachan Exp $
-->


<chapter id="design">
	<title>
	原案: &fml8; (仮名) のデザインコンセプト
	</title>


<!-- ========================================================
		section 1
     ========================================================
-->

<sect1 id="design.overview">
	<title>
	fml-devel プロジェクトの構想
	</title>

<para>
<ulink url="http://www.fml.org/software/fml8/">
fml-devel
</ulink>
とも呼ばれている &fml8; プロジェクトは、
&fml4; の再構想(refactoring)とその実装(例)の構築
を行なっています。
</PARA>

<para>
<ulink url="http://www.fml.org/software/fml8/">
http://www.fml.org/software/fml8/
</ulink>
は将来の fml-current についてのデザインや実装例を紹介しています。
</PARA>


<para>
現状の fml-devel はアイデアを実装し、運用テストするための fml 8.0 のア
ルファ版です。ですが、すでに動く実装例をダウンロードできますし、fml
1.2 相当ないしはそれ以上の機能を使うこともできます。しかしながら、変数
名もアーキテクチャアも本決まりではないので、将来変わる可能性があります。
でも、概ね固まったと思う。
</PARA>

<para>
自分がふだん使うには全然困らないのですが、&fml4; との互換性をいいだす
と、まだ多くの機能が実装されていないといえます。これは、デザインを最初
から考え直すに当たり、アイデアや意見を募集するためにまだまだ原型にとど
まっているためでもあります。
</PARA>

<para>
ものによっては &fml8; 用に作られたモジュールを &fml4; へ輸入/輸出
することも検討しています。IPv6 はすでに輸出されました。たとえば 4.0 で
も独立性の高い mead (エラーメール解析プログラム)などはその良い例だろう
し、新機能を提供するモジュールなども再輸入(輸出)可能なものは順次マージ
していきます。
</PARA>

<para>
これらのマージおよび 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 )ということになります。
</PARA>

</sect1>


<!-- ======================================================== -->

<sect1 id="design.idea.detail">
	<title>
	構想（詳細)
	</title>

<itemizedlist>

   <listitem>
	<para>
	設定ファイルとメニュープログラムの負荷を少なくしたい
	</para>
   </listitem>

   <listitem>
	<para>
	全部 perl module 形式 (要 perl 5.00504 以降)
	</para>
   </listitem>

   <listitem>
	<para>
	CUI (makefml) インターフェイスおよび CGI インターフェイス
	</para>
	<para>
	これは従来通りのもの。
	ただしより統合化され、
	よりメニューなどが書きやすいものであるように
	(実装者が楽できる設定ファイル形式がのぞましい et.al.)
	</para>
   </listitem>

   <listitem>
	<para>
	乖離層
	</para>

	<itemizedlist>

	   <listitem>
		<para>
		<link linkend="upgrade">バージョンアップ</link>
		を簡単にできるように
		</para>
	   </listitem>

	   <listitem>
		<para>
		CPAN モジュール使いまくり
		 (ただし、できるだけ直接使うより、
		一層被せておくほうがよい)
		</para>
	   </listitem>

	   <listitem>
		<para>
		3rd party 用ディレクトリ
		</para>
	   </listitem>

	</itemizedlist>
   </listitem>

   <listitem>
	<para>
	統一化されたメンバーリストなどへのアクセスをできるだけ抽象化する。
	</para>

		<itemizedlist>

		   <listitem>
			<para>
				ファイル (実装済み)
			</para>
		   </listitem>

		   <listitem>
			<para>
				/etc/group (実装済み)
			</para>
		   </listitem>

		   <listitem>
			<para>
				NIS (実装済み)
			</para>
		   </listitem>

		   <listitem>
			<para>
				SQL (MySQL は実装済み)
			</para>
		   </listitem>

		   <listitem>
			<para>
				LDAP
			</para>
		   </listitem>

	</itemizedlist>

	<para>
	実際には効率の問題もあり、
	あらゆる抽象化は重たくなってしまう。
	しかし少々重くなっても実装しよう。
	</para>
   </listitem>

   <listitem>
	<para>
	IPv4/IPv6 ready (実装済み)
	</para>
   </listitem>

</itemizedlist>
</sect1>


<!-- ======================================================== -->
<sect1 id="design.refactoring">
	<title>
	fml をリファクトリングするアイデア
	</title>

<table>
 <title> リファクトリング TODO </title>
 <tgroup cols=3>

  <thead>
	<row>
	<entry> status	</entry>
	<entry> 項目	</entry>
	<entry> 詳細	</entry>
	</row>
   </thead>

  <tbody>
	<row>
	<entry>	done. 		</entry>
	<entry> ライセンス	</entry>
	<entry>	ライセンスを Perl 準拠へ変更する	</entry>
	</row>

	<row>
	<entry>	</entry>
	<entry> イメージ/モティーフ</entry>
	<entry>
		&fml4; から &fml8; へは、
		sendmail から postfix への移行のようなイメージで。
		最低限の config.ph コンバータは用意する。
	</entry>
	</row>

	<row>
	<entry>	done. 		</entry>
	<entry>
		メインプログラムの wrapper (乖離層)。
	</entry>
	<entry>
		バージョン管理やデバッグを簡単にするための乖離層
	</entry>
	</row>

	<row>
	<entry>	</entry>
	<entry> 再利用性(自主開発はできるだけ避ける) </entry>
	<entry>
		可能な限りあらゆる CPAN モジュールなどを使う。

		そして利用する場合には乖離層を設けること。
		例えば
		”FML::モジュール →  乖離層 → CPAN/モジュール”
		のように。
	</entry>
	</row>


	<row>
	<entry>	</entry>
	<entry>
	設定ファイルの形式は
		cf と config.ph を統合化したようなもので、
		配列を表現できる形式とする。
		メニュープログラムが楽できるフォーマットにしたい。
		原則として”設定ファイル”という名のものは
		どれも同じフォーマットとする。
	</entry>
	<entry>
	</entry>
	</row>


	<row>
	<entry>	</entry>
	<entry> 変数の命名規則の規格化
	</entry>
	<entry>
		”USE_ほえ”および”ほえ_TYPE”形式か？
		また、NOT_USE などは禁止する( default_config に書くこと)。

		attribute にあたるものが
		群れになってしまうのはしょうがない。しかし、
		配列表現が可能なため、現在の ifdef の群れで表現する
		ようなことが少なくなるはず。
	</entry>
	</row>


	<row>
	<entry> </entry>
	<entry>	 関数名ルールの統一

	main:: スペースに出てくるものは従来通り X11 風準拠に。

	メソッドは他のモジュールにあるようなそれっぽい小文字の名前をつける。

	lisp 的要素を廃止する。
	</entry>

	<entry>
		参考文献 Perl Cookbook として、
		そこにあるようなシンタックス風を推奨する？

		例:
		メソッドなら is_member() で、大域関数なら
		”MemberP() -> IsMember()”
	</entry>
	</row>

	<row>
	<entry> done. (でも lmtp を実装してない;-) </entry>
	<entry> queue manager </entry>
	<entry>
		再送処理のため (e.g.  smtpfeed )
	</entry>
	</row>


	<row>
	<entry>  </entry>
	<entry> tools </entry>
	<entry>
		BSD make を使わない。

		C 言語ではないので、autoconf は特には必要ないと思う。
		しかしながら configure という名前のスクリプトを（フェイクでも）
		用意することはよいことかもしれない。

		(と、最初はいっていたけど、結局つかってます:-)

		そのスクリプトは例えば
		IPv6 ready か否かを決めるために使われるだろう(
		現在の実装では使ってはいない、IPv6 は常に挑戦してみる
		)。
	</entry>
	</row>
   </tbody>
 </tgroup>
</table>

</sect1>







<!-- ======================================================== -->
<sect1 id="design.architecture.image">
	<title>
	アーキテクチャア・イメージ
	</title>

<graphic entityref="image.architecture"></graphic>

</sect1>



<!-- ======================================================== -->

<sect1 id="design.releng">
	<TITLE>
	リリース・エンジニアリングについて (目標！)
	</TITLE>

<para>
アーキテクトでも、デベロッパーに偏ってもいけない。
抽象化に萌過ぎても、オブジェクト指向分析に燃え過ぎてもいけない。
中庸であり、一カ月単位でフィードバックしながら
プロジェクトの計画とコードレビューを行なうこと。
</para>


<para>
<table>
 <title> リリース・インターバル </title>
 <tgroup cols=2>
   <thead>
	<row>
	<entry> 日取り </entry>
	<entry> 内容 </entry>
	</row>
   </thead>

   <tbody>

	<row>
	<entry> 最初の 4〜5日</entry>
	<entry> 計画を練り直す。
		リリースエンジニアリングプロセス中の
		20 ％程度はこの計画に費やすこと
	</entry>
	</row>

	<row>
	<entry> 2〜3 週間</entry>
	<entry> コードを書く</entry>
	</row>

	<row>
	<entry> 最終週</entry>
	<entry> ドキュメントを見直す、およびコードレビュー</entry>
	</row>

	<row>
	<entry> 月の切れ目</entry>
	<entry> まぁまぁ大丈夫ぽい snapshot を出してみる。
		alpha-0,
		alpha-1,
		alpha-2, ...
	</entry>
	</row>

   </tbody>
 </tgroup>
</table>
</para>


</sect1>


</chapter>
