NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/sys5/r4/572

Internet Message Format | 1992-11-20 | 4.5 KB

Xref: sparky comp.unix.sys5.r4:572 comp.mail.misc:3754
Newsgroups: comp.unix.sys5.r4,comp.mail.misc
Path: sparky!uunet!UB.com!daver!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: [e-mail] (Bruce Lilly)
Subject: Re: Email header problems on SVR4.
Keywords: SVR4.2, mail
References: <[e-mail]> <[e-mail]> <[e-mail]>
Followup-To: comp.mail.misc
Organization: Bruce Lilly
Date: Sat, 21 Nov 92 00:52:58 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Bruce Lilly)
Lines: 79

In article <[e-mail]> [e-mail] (Tony L. Hansen) wrote:
>Isn't it better, though, to spend your time tuning the more general program
>to handle using its tools more efficiently? That way the performance of the
>entire system is improved. The use of external tools then becomes a minor
>matter.

Perhaps, providing:
1)    one has the source code to the tools, and the necessary
    tool-modification tools and performance-evaluation tools
    (and time, and expertise) to do the tuning
and
2)    the interface has been sufficiently well-designed so
    that the tools can be readily used to do the necessary
    tasks (otherwise creeping featurism (such-and-such a
    flag to alter the semantics to work better with program
    foobar) tends to result)

I say perhaps because in addition to the tools themselves, the
system hardware and software has an impact. For example, if the
OS has a fixed process table size, or has limited swap sapce,
the "tools" philosophy can result in random processes being
killed due to OS or hardware limitations. What happens to the
mail processing then (if one of the processes killed is involved
with processing the mail)?  Of course, assuming one has source
code for the OS, and the necessary tools, and further assuming
that the OS has been designed in a manner conducive to
modification, one could "tune" the OS to alleviate some of these
problems...

The "tools" approach is probably best for typical interactive
user processes, so that a user can perform a task by combining
tools in an appropriate manner.  If Joe R. User's interactive
process is killed due to system loading, Joe can always try
again later. But for daemon processes where high availability
and reliability are desired, given the characteristics of most
versions of the UNIX(R) operating system, blind dependence on
the system having enough resources to accomodate additional
processes and programs used by fork/exec may lead to problems.

Having said that, there is still place for a generic "tools"
approach:
a)    ancillary programs can be used to prepare and maintain
    databases used by mail delivery programs. e.g. pathalias
    (not the SVR4 pathalias(4)). I don't know of any mail
    delivery agents that grope through the raw UUCP maps to
    calculate a path each time one is needed.
b)    if the program is itself programmable (somebody recently
    pointed out that sendmail's programming language as used
    in its configuration file is Turing-complete), "tools"
    can be crafted without the need for fork/exec and
    external programs. For example, the sendmail.cf file
    used here has a large number of (relatively) simple
    rulesets, which are called as subroutines for header
    processing and mailer selection.

Another limitation of the fork/exec tools approach is the
portability issue. Granted, a "monolithic" C program requires
many contortions to address portability across various software
platforms. But the same is true of the "tools" approach. There
are many varieties of sed, awk/nawk/gawk/mawk, grep/egrep,
shells, etc. which may respond differently (output format,
features, arguments, regexps, return values) on different
systems. Take a look at the C news scripts for examples of the
contortions which are necessary to accomodate some of these
differences. Use of the external tools approach makes the
overall (mail handling) system vulnerable to bugs and
implementation dependencies in the various external programs
used. In addition to having to port the master program (which
forks and execs the tools) to various platforms, the
configuration files may have to be modified to accommodate
differences in the tools available on the different platforms.
A configuration which works perfectly with the tools on one
system may fail spectacularly on another system with nominally
the same tools (grep always returns 0 if any match is found,
right?).

--
    Bruce Lilly        blilly![e-mail]
                    ...uunet!sonyusa!sonyd1!blilly!bruce