Traditionally, a server is a machine or a piece of software that one connects to, and then requests information from. Gnus does not connect directly to any real servers, but does all transactions through one backend or other. But that's just putting one layer more between the actual media and Gnus, so we might just as well say that each backend represents a virtual server.
For instance, the nntp
backend may be used to connect to several
different actual nntp servers, or, perhaps, to many different ports on
the same actual nntp server. You tell Gnus which backend to use, and
what parameters to set by specifying a select method.
These select methods specifications can sometimes become quite complicated - say, for instance, that you want to read from the nntp server `news.funet.fi' on port number `13', which hangs if queried for NOV headers and has a buggy select. Ahem. Anyways, if you had to specify that for each group that used this server, that would be too much work, so Gnus offers a way of putting names to methods, which is what you do in the server buffer.
You can change the look of the server buffer lines by changing the
gnus-server-line-format
variable. This is a format
-like
variable, with some simple extensions:
gnus-server-read-server
).
gnus-server-exit
).
gnus-server-list-servers
).
gnus-server-kill-server
).
gnus-server-yank-server
).
gnus-server-copy-server
).
gnus-server-add-server
).
gnus-server-edit-server
).
Most select methods are pretty simple and self-explanatory:
(nntp "news.funet.fi")
Reading directly from the spool is even simpler:
(nnspool "")
As you can see, the first element in a select method is the name of the backend, and the second is the address, or name, if you will.
After these two elements, there may be a random number of (variable form) pairs.
To go back to the first example - imagine that you want to read from
port 15
from that machine. This is what the select method should
look like then:
(nntp "news.funet.fi" (nntp-port-number 15))
You should read the documentation to each backend to find out what
variables are relevant, but here's an nnmh
example.
nnmh
is a mail backend that reads a spool-like structure. Say
you have two structures that you wish to access: One is your private
mail spool, and the other is a public one. Here's the possible spec for
you private mail:
(nnmh "private" (nnmh-directory "~/private/mail/"))
(This server is then called `private', but you may have guessed that.
Here's the method for the public spool:
(nnmh "public" (nnmh-directory "/usr/information/spool/") (nnmh-get-new-mail nil))
Wherever you would normally use a select method
(eg. gnus-secondary-select-method
, in the group select method,
when browsing a foreign server) you can use a virtual server name
instead. This could potentially save lots of typing. And it's nice all
over.