gnus: Terminology

 
 11.4 Terminology
 ================
 
 “news”
      This is what you are supposed to use this thing for—reading news.
      News is generally fetched from a nearby NNTP server, and is
      generally publicly available to everybody.  If you post news, the
      entire world is likely to read just what you have written, and
      they’ll all snigger mischievously.  Behind your back.
 
 “mail”
      Everything that’s delivered to you personally is mail.  Some
      news/mail readers (like Gnus) blur the distinction between mail and
      news, but there is a difference.  Mail is private.  News is public.
      Mailing is not posting, and replying is not following up.
 
 “reply”
      Send a mail to the person who has written what you are reading.
 
 “follow up”
      Post an article to the current newsgroup responding to the article
      you are reading.
 
 “back end”
      Gnus considers mail and news to be mostly the same, really.  The
      only difference is how to access the actual articles.  News
      articles are commonly fetched via the protocol NNTP, whereas mail
      messages could be read from a file on the local disk.  The internal
      architecture of Gnus thus comprises a “front end” and a number of
      “back ends”.  Internally, when you enter a group (by hitting <RET>,
      say), you thereby invoke a function in the front end in Gnus.  The
      front end then “talks” to a back end and says things like “Give me
      the list of articles in the foo group” or “Show me article number
      4711”.
 
      So a back end mainly defines either a protocol (the ‘nntp’ back end
      accesses news via NNTP, the ‘nnimap’ back end accesses mail via
      IMAP) or a file format and directory layout (the ‘nnspool’ back end
      accesses news via the common “spool directory” format, the ‘nnml’
      back end access mail via a file format and directory layout that’s
      quite similar).
 
      Gnus does not handle the underlying media, so to speak—this is all
      done by the back ends.  A back end is a collection of functions to
      access the articles.
 
      However, sometimes the term “back end” is also used where “server”
      would have been more appropriate.  And then there is the term
      “select method” which can mean either.  The Gnus terminology can be
      quite confusing.
 
 “native”
      Gnus will always use one method (and back end) as the “native”, or
      default, way of getting news.  Groups from the native select method
      have names like ‘gnu.emacs.gnus’.
 
 “foreign”
      You can also have any number of foreign groups active at the same
      time.  These are groups that use non-native non-secondary back ends
      for getting news.  Foreign groups have names like
      ‘nntp+news.gmane.org:gmane.emacs.gnus.devel’.
 
 “secondary”
      Secondary back ends are somewhere half-way between being native and
      being foreign, but they mostly act like they are native, but they,
      too have names like ‘nntp+news.gmane.org:gmane.emacs.gnus.devel’.
 
 “article”
      A message that has been posted as news.
 
 “mail message”
      A message that has been mailed.
 
 “message”
      A mail message or news article
 
 “head”
      The top part of a message, where administrative information (etc.)
      is put.
 
 “body”
      The rest of an article.  Everything not in the head is in the body.
 
 “header”
      A line from the head of an article.
 
 “headers”
      A collection of such lines, or a collection of heads.  Or even a
      collection of NOV lines.
 
 “NOV”
      NOV stands for News OverView, which is a type of news server header
      which provide datas containing the condensed header information of
      articles.  They are produced by the server itself; in the ‘nntp’
      back end Gnus uses the ones that the NNTP server makes, but Gnus
      makes them by itself for some backends (in particular, ‘nnml’).
 
      When Gnus enters a group, it asks the back end for the headers of
      all unread articles in the group.  Most servers support the News
      OverView format, which is more compact and much faster to read and
      parse than the normal HEAD format.
 
      The NOV data consist of one or more text lines (SeeMotion by
      Text Lines (elisp)Text Lines.) where each line has the header
      information of one article.  The header information is a
      tab-separated series of the header’s contents including an article
      number, a subject, an author, a date, a message-id, references,
      etc.
 
      Those data enable Gnus to generate summary lines quickly.  However,
      if the server does not support NOV or you disable it purposely or
      for some reason, Gnus will try to generate the header information
      by parsing each article’s headers one by one.  It will take time.
      Therefore, it is not usually a good idea to set nn*-nov-is-evil
      (SeeSlow/Expensive Connection) to a non-‘nil’ value unless you
      know that the server makes wrong NOV data.
 
 “level”
      Each group is subscribed at some “level” or other (1–9).  The ones
      that have a lower level are “more” subscribed than the groups with
      a higher level.  In fact, groups on levels 1–5 are considered
      “subscribed”; 6–7 are “unsubscribed”; 8 are “zombies”; and 9 are
      “killed”.  Commands for listing groups and scanning for new
      articles will all use the numeric prefix as “working level”.
 
 “killed groups”
      No information on killed groups is stored or updated, which makes
      killed groups much easier to handle than subscribed groups.
 
 “zombie groups”
      Just like killed groups, only slightly less dead.
 
 “active file”
      The news server has to keep track of what articles it carries, and
      what groups exist.  All this information in stored in the active
      file, which is rather large, as you might surmise.
 
 “bogus groups”
      A group that exists in the ‘.newsrc’ file, but isn’t known to the
      server (i.e., it isn’t in the active file), is a _bogus group_.
      This means that the group probably doesn’t exist (any more).
 
 “activating”
      The act of asking the server for info on a group and computing the
      number of unread articles is called “activating the group”.
      Un-activated groups are listed with ‘*’ in the group buffer.
 
 “spool”
      News servers store their articles locally in one fashion or other.
      One old-fashioned storage method is to have just one file per
      article.  That’s called a “traditional spool”.
 
 “server”
      A machine one can connect to and get news (or mail) from.
 
 “select method”
      A structure that specifies the back end, the server and the virtual
      server settings.
 
 “virtual server”
      A named select method.  Since a select method defines all there is
      to know about connecting to a (physical) server, taking the thing
      as a whole is a virtual server.
 
 “washing”
      Taking a buffer and running it through a filter of some sort.  The
      result will (more often than not) be cleaner and more pleasing than
      the original.
 
 “ephemeral groups”
      Most groups store data on what articles you have read.  “Ephemeral”
      groups are groups that will have no data stored—when you exit the
      group, it’ll disappear into the aether.
 
 “solid groups”
      This is the opposite of ephemeral groups.  All groups listed in the
      group buffer are solid groups.
 
 “sparse articles”
      These are article placeholders shown in the summary buffer when
      ‘gnus-build-sparse-threads’ has been switched on.
 
 “threading”
      To put responses to articles directly after the articles they
      respond to—in a hierarchical fashion.
 
 “root”
      The first article in a thread is the root.  It is the ancestor of
      all articles in the thread.
 
 “parent”
      An article that has responses.
 
 “child”
      An article that responds to a different article—its parent.
 
 “digest”
      A collection of messages in one file.  The most common digest
      format is specified by RFC 1153.
 
 “splitting”
      The action of sorting your emails according to certain rules.
      Sometimes incorrectly called mail filtering.