First, just for terminology, the back end is the common word for a low-level access method--a transport, if you will, by which something is acquired. The sense is that one's mail has to come from somewhere, and so selection of a suitable back end is required in order to get that mail within spitting distance of Gnus.
The same concept exists for Usenet itself: Though access to articles is
typically done by NNTP these days, once upon a midnight dreary, everyone
in the world got at Usenet by running a reader on the machine where the
articles lay (the machine which today we call an NNTP server), and
access was by the reader stepping into the articles' directory spool
area directly. One can still select between either the nntp
or
nnspool
back ends, to select between these methods, if one happens
actually to live on the server (or can see its spool directly, anyway,
via NFS).
The goal in selecting a mail back end is to pick one which simultaneously represents a suitable way of dealing with the original format plus leaving mail in a form that is convenient to use in the future. Here are some high and low points on each:
nnmbox
nnbabyl
nnml
nnml
is the back end which smells the most as though you were
actually operating with an nnspool
-accessed Usenet system. (In
fact, I believe nnml
actually derived from nnspool
code,
lo these years ago.) One's mail is taken from the original spool file,
and is then cut up into individual message files, 1:1. It maintains a
Usenet-style active file (analogous to what one finds in an INN- or
CNews-based news system in (for instance) `/var/lib/news/active',
or what is returned via the `NNTP LIST' verb) and also creates
overview files for efficient group entry, as has been defined for
NNTP servers for some years now. It is slower in mail-splitting,
due to the creation of lots of files, updates to the nnml
active
file, and additions to overview files on a per-message basis, but it is
extremely fast on access because of what amounts to the indexing support
provided by the active file and overviews.
nnml
costs inodes in a big way; that is, it soaks up the
resource which defines available places in the filesystem to put new
files. Sysadmins take a dim view of heavy inode occupation within
tight, shared filesystems. But if you live on a personal machine where
the filesystem is your own and space is not at a premium, nnml
wins big.
It is also problematic using this back end if you are living in a
FAT16-based Windows world, since much space will be wasted on all these
tiny files.
nnmh
nnmh
is considered to be semantically equivalent to "nnml
without
active file or overviews". This is arguably the worst choice, because
one gets the slowness of individual file creation married to the
slowness of access parsing when learning what's new in one's groups.
nnfolder
nnfolder
is nnmbox
(the first
method described above) on a per-group basis. That is, nnmbox
itself puts *all* one's mail in one file; nnfolder
provides a
little bit of optimization to this so that each of one's mail groups has
a Unix mail box file. It's faster than nnmbox
because each group
can be parsed separately, and still provides the simple Unix mail box
format requiring minimal effort in moving the mail around. In addition,
it maintains an "active" file making it much faster for Gnus to figure
out how many messages there are in each separate group.
If you have groups that are expected to have a massive amount of
messages, nnfolder
is not the best choice, but if you receive
only a moderate amount of mail, nnfolder
is probably the most
friendly mail back end all over.
Go to the first, previous, next, last section, table of contents.