docs/master: discussion.roff comparison

comparison discussion.roff @ 225:d83ab437e3a6

Removed FIXMEs (XXX) in the sources, those that I won't fix.

author	markus schnalke <meillo@marmaro.de>
date	Sun, 15 Jul 2012 20:00:14 +0200
parents	b0e83cfde2bf
children	27c28990b844

comparison

equal deleted inserted replaced

-:b0e83cfde2bf
+:d83ab437e3a6
 to be beaten by projects that focus exclusively on the creation
 of a homogeneous system by integrating existing mail components.
 .P
 Usually, the limiting resource in the community development of
 free software is man power.
-.\" XXX FIXME ref!
 If the development effort is spread over a large development area,
 it becomes more difficult to compete with the specialists in the
 various fields.
 The concrete situation for MH-based mail systems is even tougher,
 given their small and aged community, concerning both developers and users.
 They likely are superior to the internal versions that were removed.
 Additionally, the best suiting programs can be chosen freely.
 .P
 As it had already been possible to use an external MSA and MRA,
 why should the internal version not be kept for convenience?
-.\" XXX commas correct?
 Transfered to a different area, the question,
 whether there is sense in having a fall-back pager in all
 the command line tools for the cases when
 .Pn more
 or
 .LI 2
 By depending on a library that provides the function.
 .LI 3
 By depending on a program that provides the function.
 .LP
-.\" XXX Rework sentence
 While implementing the function in the project itself leads to the
 largest increase in code size and requires the most maintenance
 and development work,
 it keeps the project's dependence on other software lowest.
 Using libraries or external programs requires less maintenance work
 Programs have the smallest interfaces and provide the best separation,
 but possibly limit the information exchange.
 External libraries are more strongly connected than external programs,
 thus information can be exchanged in a more flexible manner.
 Adding code to a project increases maintenance work.
-.\" XXX ref
 As implementing complex functions in the project itself adds
 a lot of code, this should be avoided if possible.
 Thus, the dependencies only change in their character,
 not in their existence.
 In mmh, library dependencies on
 .Fn /etc/group
 for consistency, which is completely unrelated to email.
 A tool like
 .Pn conflict
 is surely useful, but it should not be shipped with mmh.
-.\" XXX historic reasons?
 .BU
 .Pn rcvtty
 was removed
 .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
 because its use case of writing to the user's terminal
 .VS
 scan -file - | write `id -un`
 VE
 .BU
 .Pn viamail
-.\" XXX was macht viamail
 was removed
 .Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
 when the new attachment system was activated, because
 .Pn forw
 could then cover the task itself.
 was rewritten as a shell script wrapper around
 .Pn forw .
 .Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
 .BU
 .Pn msgchk
-.\" XXX was macht msgchk
 was removed
 .Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe ,
 because it lost its use case when POP support was removed.
 A call to
 .Pn msgchk
 .H2 "Displaying Messages
 .Id mhshow
 .P
 Since the very beginning, already in the first concept paper,
-.\" XXX ref!!!
 .Pn show
 had been MH's message display program.
 .Pn show
 mapped message numbers and sequences to files and invoked
 .Pn mhl
 .Pn mhshow
 was reworked to behave more like
 .Pn show
 first (cf. Sec.
 .Cf mhshow ).
-.\" XXX code commits?
 Once the tools behaved more alike, the replacing appeared to be
 even more natural.
 Today, mmh's new
 .Pn show
 has become the one single message display program once again,
 Still, removing the old
 .Pn show
 hurts in one regard: It had been such a simple program.
 Its lean elegance is missing from the new
 .Pn show ,
-.\" XXX
+but there is no alternative;
-however there is no alternative;
 supporting MIME demands higher essential complexity.
-.ig
-XXX
-Consider including text on scan listings here
-Scan listings shall not contain body content. Hence, removed this feature.
-Scan listings shall operator on message headers and non-message information
-only. Displaying the beginning of the body complicates everything too much.
-That's no surprise, because it's something completely different. If you
-want to examine the body, then use show(1)/mhshow(1).
-Changed the default scan formats accordingly.
-.Ci 70b2643e0da8485174480c644ad9785c84f5bff4
-..
 .H2 "Configure Options
 .P
 With
 .Sw --with-smtpservers
 default SMTP servers could be specified
 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9 .
 Both of them became irrelevant when the SMTP transport service was removed.
-.\" XXX code ref
 In mmh, all messages are handed over to
 .Pn sendmail
 for transportation.
 .U3 "Backup Prefix
 .P
 The backup prefix is the string that was prepended to message
 filenames to tag them as deleted.
 By default it had been the comma character (`\fL,\fP').
-.\" XXX Zeitlich ordnen
 In July 2000, Kimmo Suominen introduced
 the configure option
 .Sw --with-hash-backup
 to change the default to the hash character `\f(CW#\fP'.
 This choice was probably personal preference, but,
 .I ndbm
 vanished and 120 lines of complex autoconf code could be saved
 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf .
 The change removed functionality but that is considered minor to the
 improvement of dropping the dependency and the complex autoconf code.
-.\" XXX argument: slocal ist sowieso nicht teil vom mmh kern
 .U3 "MH-E Support
 .P
 The configure option
 .Sw --disable-mhe
 The decision to remove this username_extension masquerading
 was motivated by the fact that
 .Pn spost
 had not supported it yet.
 Username extensions can be used in mmh, but less convenient.
-.\" XXX covered by next paragraph
+.\" XXX In the format file: %(getenv USERNAME_EXTENSION)
-.\" XXX format file %(getenv USERNAME_EXTENSION)
 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
 .P
 The
 .I draft_from
 masquerading type instructed
 .H2 "Command Line Switches
 .P
 The command line switches of MH tools follow a style similar to
 the X Window System style.
-.\" XXX ref
 The switches consist of a single dash (`\fL-\fP') followed by a word.
 For example
 .Cl -truncate .
 To ease typing, the word can be abbreviated, given the remaining
 prefix is unambiguous.
 If one task should be accomplished in various ways,
 switches are a good approach to alter the behavior of a program.
 Changing the behavior of programs provides flexibility and customization
 to users, but at the same time it complicates the code,
 the documentation, and the usage of the program.
-.\" XXX: Ref
 Therefore, the number of switches should be kept small.
 A small set of well-chosen switches is best.
 Usually, the number of switches increases over time.
 Already in 1985, Rose and Romine have identified this as a major
 problem of MH:
 let's push forward, aggressively.
 .QE
 .LP
 I did so already in the months before.
 I pushed forward.
-.\" XXX semicolon ?
 I simply dropped the cruft.
 .P
 The decision to drop a feature was based on literature research and
 careful thinking, but whether having had contact with this particular
 feature within my own computer life served as a rule of thumb.
 Hence, others can comprehend my view and argue for undoing the change
 if I have missed an important aspect.
 I was quick in dropping parts.
 I rather include falsely dropped parts again, than going at a slower pace.
 Mmh is experimental work; it requires tough decisions.
-.\" XXX ``exp. work'' schon oft gesagt
 .U3 "Process Forking
 .P
 Being a tool chest, MH creates many processes.
 and parts of arbitrary type following.
 .P
 MH's MIME support is a direct implementation of the RFCs.
 The perception of the topic described in the RFCs is clearly visible
 in MH's implementation.
-.\" XXX rewrite ``no idea''.
 As a result,
 MH had all the MIME features but no idea of attachments.
 But users do not need all the MIME features,
 they want convenient attachment handling.
 MIME parts of type message/external-body are not automatically retrieved
 anymore.
 Instead, information on how to retrieve them is output.
 Not supporting this rare case saved nearly one thousand lines of code
 .Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32 .
-.\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
-.\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
 The MIME type `application/octet-stream; type=tar' is not special anymore.
 The automatically extracting of such MIME parts had been the
 dangerous part of the
 .Sw -auto
 mode
 in a single pager session.
 Non-text content needs to be converted to text by appropriate
 .Pe mhshow-show-*
 profile entries before, if this is possible and wanted.
 A common example for this are PDF files.
-.ig \"XXX
-.Pe mhshow-show-*
-profile entries can be used to display MIME parts in a specific way.
-to display them in the terminal.
-..
 In mmh, MIME parts are always displayed serially.
 The request to display the MIME type `multipart/parallel' in parallel
 is ignored.
 It is simply treated as `multipart/mixed'
 .Ci d0581ba306a7299113a346f9b4c46ce97bc4cef6 .
 This is the function of choice for path conversion.
 Absolute directory paths are the most general representation of a
 path name.
 The result is a pointer to static memory.
 .P
-.\" XXX ueberfluessig?
 The new functions have names that indicate their use.
 Two of the functions convert relative to absolute path names of the
 same type.
 The third function converts any path name type to the most general one,
 the absolute directory path.
 .Ci 0052f1024deb0a0a2fc2e5bacf93d45a5a9c9b32 .
 Such decisions limit the portability of mmh
 if systems do not support these standardized and widespread functions.
 This compromise is made because mmh focuses on the future.
 .P
-.\" XXX kuerzen und mit dem naechsten Absatz vereinen
 As I am still in my twenties, have no programming experience from
 past decades.
 I have not followed the evolution of C through time.
 I have not suffered from the the Unix wars.
 I have not longed for standardization.
 This is a ratio of 1.3 source files per program.
 18 programs depend on multiple source files;
 21 programs depend on one source file only.
 (These numbers and the ones in the following text ignore the MH library
 as well as shell scripts and multiple names for the same program.)
-.\" XXX graph
 .P
 Splitting the source code of a large program into multiple files can
 increase the readability of its source code,
 but most of the mmh tools are small and straight-forward programs.
 In exception of the MIME handling tools (i.e.

Mercurial > docs > master

comparison discussion.roff @ 225:d83ab437e3a6