<!--
   $FML: chapter.onhost.sgml,v 1.3 2005/09/18 13:55:56 fukachan Exp $
   $jaFML: chapter.onhost.sgml,v 1.8 2003/04/15 14:51:46 fukachan Exp $
-->

<chapter id="usage.onhost">
	<title>
	What Can You Do On The Mailing List Server
	</title>


<para>
On the host which serves ML driver, you can use CUI (makefml and fml)
and edit all configuration files as you like.  It implies you are the
greatest administrator :)
</para>

<para>
"makefml" command of &fml8; is same as &fml4; as could as possible to
preserve compatibility.
</para>

<para>
See
<link linkend="changes.cui">
<xref linkend="changes.cui">
</link>
on the detail of the difference.
</para>


<sect1 id="usage.onhost.priviledge">
	<title>
	On The Host
	</title>

<para>
You need no confirmation in using makefml.
</para>

<para>
Person who can login the host of mailing list server has priviledge
for all ML's on the host.  So, He/She can edit all configuration
files.
</para>

<para>
But He/She may do wrong operations.
</para>

<para>
To avoid careless wrong operations, in usual cases you should use CUI
(makefml or fml) to configure fml.  Of course you can edit files
directly if you can understand fml structures. By default we recommend
you should use CUI always on the host.
</para>

<para>
"fml" command is same as "makefml" command except for the argument
order.
<screen>
makefml COMMAND ML OPTIONS
fml     ML COMMAND OPTIONS
</screen>
Please either as you like.
</para>

</sect1>


<sect1 id="usage.commandpolicy">
	<title>
	Policy Of Command Creation
	</title>

<para>
&fmldevel; provides a different command for each function. Its policy
makes the number of commands infinite. So, except for some special
cases, we should unify all functions into makefml/fml command since
such commands can be shared among CUI, GUI and commmnd mail.
</para>


<sect2>
	<title>
	Operation May Modify The Specific ML (Read + Write)
	</title>

<para>
We should implement sub-command of makefml/fml when some operation may
modify the specific ML.
</para>

</sect2>


<sect2>
	<title>
	Operation For Read Only Data Of The Specific ML (Read Only)
	</title>

<para>
We should implement it as a makefml/fml command since it is related to
the specific ML.
</para>

</sect2>


<sect2>
	<title>
	Show The General Data (Read Only)
	</title>

<para>
If the data is not related to the specific ML, for example,
see the module manual, aliases on the host, 
we implement specific commands other than makefml/fml.
This command name begins with "fml" prefix.
<screen>
fmladdr	 [-n]
fmlalias [-n]
fmldoc   MODULE
fmlconf  [-n] ML
</screen>
</para>

</sect2>


<sect2>
	<title>
	ML Specific But A Command Wrapper
	</title>

<para>
PGP / GPG related command (e.g. fmlpgp) is very command speicific.
So, it looks difficult to incorporate them into "makefml" and "fml"
framework. So we implement it as another command such as fmlpgp,
fmlgpg, ...
</para>

</sect2>

<sect2>
	<title>
	Misc
	</title>

<para>
We implement specific commands other than makefml/fml.
This command name begins with fml prefix.
</para>

<para>
For example, "fmlhtmlify" is a conveter from text to html form.
This command is used to convert both fml spool and MH folders.
<screen>
fmlhtmlify [-I DIR] $src_dir $dst_dir
</screen>
</para>

</sect2>


</sect1>


<sect1 id="usage.command.line.options">
	<title>
	Common Command Line Options
	</title>

<para>
Programs under libexec/ and bin/ supports 
the following common command line options.
<screen>
--debug
--help
-c file
-o key=value
</screen>
Use -c to specify non default main.cf path.
-o overwrites configuration variables.
Plural -o are acceptable.
<screen>
-o key1=value1 -o key2=value2
</screen>
</para>

</sect1>


&sect.usage.makefml;
&sect.usage.fml;
&sect.usage.fmladdr;
&sect.usage.fmlalias;
&sect.usage.fmlconf;
&sect.usage.fmldoc;
&sect.usage.fmlhtmlify;

<sect1 id="usage.recipes">
	<title>
	Recipes
	</title>

&sect.usage.onhost.recipes;

</sect1>

</chapter>
