<!-- 
	すでに <chapter> 〜 </chapter> の中で include されていることに注意

	$FML: intro.sgml,v 1.3 2001/04/22 12:45:46 fukachan Exp $
-->

<title>fml5 (仮名) プロジェクトの目的</title>
  
<para>
fml-devel は将来 fml 5.0 になるであろうという… 
</para>


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

<sect1>

<title> fml-devel プロジェクトの構想 </title>


<para>
fml-devel とも呼ばれている fml 5.0 プロジェクトは、
fml 4.0 の再構想(refactoring)とその実装(例)の構築
を行なっています。
</PARA>

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


<para>
これは fml 5.0 のアイデアを募るための、
fml 5.0 のアルファ版のアルファ版のアルファ版
もしくは
プロトタイプ
とでもいうべきものです。ですが、すでに動く実装例をダウンロードできます
し、fml 1.2 相当の機能を使うこともできます。しかしながら、変数名もアー
キテクチャアも本決まりではないので、将来変わる可能性があります。
</PARA>

<para>
また、多くの機能が実装されていません。これは、デザインを最初から考え直
すに当たり、アイデアや意見を募集するためにまだまだ原型にとどまっている
ためでもあります。
</PARA>

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

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

</sect1>


<!-- ========================================================
		section 2
     ========================================================
-->

<sect1>

<title> 開発ブランチの関係  </title>

<programlisting>
             -----------------------------> 5.0 (本プロジェクトの目標)
                       ↑↓交流
1.2  〜 4.0 ------------------------------> 4.0-current
              |      |
            4.0.1   4.0.2 .... (リリース / 4.0-stable バージョン)
</programlisting>

</sect1>


<!-- ========================================================
		section 3
     ========================================================
-->

<sect1>

<title> 構想（詳細）</title>

<para>
5.0 のアイデアのついて、ご意見・御感想をお待ちしております。
端的にいえば 4.0 のここは受け継ぎたいが、あの機能は
どうでもよいとか、あの機能はこう実装するべきだなどといった
意見も募集しています。
</para>


<itemizedlist>

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

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

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

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

	<itemizedlist>

	   <listitem>
		<para>
		バージョンアップを簡単にできるように
		</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 (プロトタイプは実装済み)
			</para>
		   </listitem>
		
		   <listitem>
			<para>
				LDAP
			</para>
		   </listitem>
		
	</itemizedlist>

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

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

</itemizedlist>
</sect1>


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

<title> アーキテクチャア・イメージ </title>

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

</sect1>
