modified to fit with created subdirectories: programs/, install/,

delivery/, internals/, devel/ and include/.

2 files changed, 616 insertions, 0 deletions

diff --git a/fml/doc/ja/tutorial/internals/design.sgml b/fml/doc/ja/tutorial/internals/design.sgml
new file mode 100644
index 00000000..efafd6ca
--- /dev/null
+++ b/fml/doc/ja/tutorial/internals/design.sgml
@@ -0,0 +1,455 @@
+<!-- 
+	$FML: design.sgml,v 1.3 2001/04/24 13:33:34 fukachan Exp $
+-->
+
+<chapter id="design">
+
+<title>fml5 (仮名) のデザインコンセプト</title>
+
+  
+<!-- ========================================================
+		section 1
+     ========================================================
+-->
+
+<sect1>
+
+<title> fml-devel プロジェクトの構想 </title>
+
+<para>
+<ulink url="http://www.fml.org/devel/">
+fml-devel 
+</ulink>
+とも呼ばれている fml 5.0 プロジェクトは、
+fml 4.0 の再構想(refactoring)とその実装(例)の構築
+を行なっています。
+</PARA>
+
+<para>
+<ulink url="http://www.fml.org/devel/">
+http://www.fml.org/devel/
+</ulink>
+は将来の fml-current についてのデザインや実装例を紹介しています。
+</PARA>
+
+
+<para>
+現状の fml-devel は 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>
+
+
+<!-- ======================================================== -->
+
+<sect1>
+
+<title> 構想（詳細）</title>
+
+<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>
+		<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 (プロトタイプは実装済み)
+			</para>
+		   </listitem>
+		
+		   <listitem>
+			<para>
+				LDAP
+			</para>
+		   </listitem>
+		
+	</itemizedlist>
+
+	<para>
+	実際には効率の問題もあり、
+	あらゆる抽象化は重たくなってしまう。
+	しかし少々重くなっても実装しよう。
+	</para>		
+   </listitem>
+
+   <listitem>
+	<para>
+	IPv4/IPv6 ready (実装済み)
+	</para>
+   </listitem>
+
+</itemizedlist>
+</sect1>
+
+
+<!-- ======================================================== -->
+<sect1>
+
+<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 から fml5 へは、
+		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>
+	設定ファイル形式
+	<itemizedlist>
+		<listitem>
+		<para>
+		 cf と config.ph を統合化する
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		 配列を表現できる形式
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		 メニュープログラムが楽できるフォーマットを
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		 原則として”設定ファイル”という名のものは
+		     どれも同じフォーマットとする。
+		</para>
+		</listitem>
+	</itemizedlist>
+	</entry>
+	<entry>
+	</entry>
+	</row>
+
+
+	<row>
+	<entry>	</entry>
+	<entry> 変数の命名規則
+	<itemizedlist>
+		<listitem>
+		<para>
+		USE_機能
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		機能_TYPE
+		</para>
+		</listitem>
+
+		<listitem>
+		<para>
+		機能_ATTRIBUTES
+		</para>
+		</listitem>
+
+	</itemizedlist>
+	</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> 手づかず </entry>
+	<entry> queue manager </entry>
+	<entry>
+		再送処理のため (e.g.  smtpfeed )
+	</entry>
+	</row>
+
+
+	<row>
+	<entry> may be </entry>
+	<entry> tools </entry>
+	<entry>
+		BSD make を使わない。
+
+		C 言語ではないので、autoconf は特には必要ないと思う。
+		しかしながら configure という名前のスクリプトを（フェイクでも）
+		用意することはよいことかもしれない。
+
+		そのスクリプトは例えば
+		IPv6 ready か否かを決めるために使われるだろう(
+		現在の実装では使ってはいない、IPv6 は常に挑戦してみる
+		)。
+	</entry>
+	</row>
+   </tbody>
+ </tgroup>
+</table>
+
+</sect1>
+
+
+
+
+
+
+
+<!-- ======================================================== -->
+<sect1>
+
+<title> アーキテクチャア・イメージ </title>
+
+<graphic entityref="architecture"></graphic>
+
+</sect1>
+
+
+
+<!-- ======================================================== -->
+
+<sect1>
+
+<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>
diff --git a/fml/doc/ja/tutorial/internals/style.sgml b/fml/doc/ja/tutorial/internals/style.sgml
new file mode 100644
index 00000000..87365aa2
--- /dev/null
+++ b/fml/doc/ja/tutorial/internals/style.sgml
@@ -0,0 +1,161 @@
+<!--
+	$FML: style.sgml,v 1.1 2001/04/26 08:58:36 fukachan Exp $
+-->
+
+<chapter id="programingstyle">
+
+<TITLE>プログラミング・スタイル</TITLE>
+
+<para>
+ここでは、プログラミング上のいくつかの諸問題についてまとめます。
+</para>
+
+
+<!-- ==================================================== -->
+<sect1 id="variable-naming-convention">
+
+<title>
+変数の命名規則（ネーミングコンベンション）
+</title>
+
+	<sect2>
+	<title> 標準パターン (例 log.cf lock.cf) </title>
+
+<screen>
+use_変数		=	yes/no
+
+# ディレクトリなら最後に _dir がつくことが望ましい
+変数_dir		=	文字列
+
+# ファイルなら最後に _file がつくことが望ましい
+変数_file		=	文字列
+
+変数_type		=	文字列
+
+変数_format		=	文字列
+
+変数_format_type	=	文字列
+
+変数_limit		=	文字列(数字だけど文字列扱い)
+
+変数_upper_limit	=	文字列(数字だけど文字列扱い)
+
+変数_lower_limit	=	文字列(数字だけど文字列扱い)
+</screen>
+
+	</sect2>
+
+	<sect2> 
+	<title> パターン２ (例 acl.cf ) </title>
+
+<screen>
+変数_restrictions	=	reject_属性 
+				permit_なんとか
+
+属性 			=	パターン1
+				パターン2
+				…
+</screen>
+	 </sect2>
+
+
+	<sect2>
+	<title> パターン3 (さらにプログラム名がつく場合) </title>
+
+<screen>
+プログラム_変数_属性
+</screen>
+	 </sect2>
+
+
+</sect1>
+
+
+<!-- ==================================================== -->
+<sect1>
+
+<title>
+プログラミング・スタイル (原案のメモ(注: 単なる走り書き))
+</title>
+
+<para>
+<itemizedlist>
+	<listitem>
+	<para>
+	
+	Perl ではポリモーフィズムと実行時バインディングができることに
+	は重視すること。多重継承などに頭を使うより
+	ポリモーフィズムと実行時バインディングによる
+	コンポーネント指向ぽい方向性を模索する。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	Perl 5 のパッケージを使った、オブジェクトぽい書き方は
+	変数自身が自分のパッケージを知っているので、
+	単にパッケージ修飾(例: :: )を使わなくてもよいくらいに
+	思う方がよい。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	そのために、
+	再利用性と抽象度を高くしたインターフェイスは
+	オブジェクトぽい書きかたが良さそう。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	perl 5 だと必然的にオブジェクトぽくなってしまうが、
+	オブジェクト、オブジェクト、オブジェクトし過ぎないように
+	バランス感覚に注意しよう。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+ 	他人のモジュールを使う場合はともかく、
+	自分達で書くモジュールでの
+	”深い”継承はできるだけ避けたい。
+	何でも深くすればよいというものではないでしょう。 
+
+	</para>
+	</listitem>
+
+</itemizedlist>
+</para>
+
+
+<para>
+	libexec/ や libkern.pl にある関数は、
+	main:: に記述される部分は基本的なフローを記述している。
+	これらは基本的な枠組を示すものであるため、
+	 $CurProc (C でいえば struct *curproc にあたるもの)
+	を受け渡す、構造化プログラミング的な書き方をしている。
+</para>
+
+
+
+<para>
+	しかし、そのひとつ下の層、そしてさらにその下では、
+	再利用性とポリモーフィズムに傾いた方がよさそうにおもえる。
+</para>
+
+</sect1>
+
+</chapter>