www.delorie.com/gnu/docs/emacs/gnus_296.html

search

	Buy the book!

Gnus Manual

10.6.2 Back End Interface

Gnus doesn't know anything about NNTP, spools, mail or virtual groups. It only knows how to talk to virtual servers. A virtual server is a back end and some back end variables. As examples of the first, we have nntp, nnspool and nnmbox. As examples of the latter we have nntp-port-number and nnmbox-directory.

When Gnus asks for information from a back end--say nntp---on something, it will normally include a virtual server name in the function parameters. (If not, the back end should use the "current" virtual server.) For instance, nntp-request-list takes a virtual server as its only (optional) parameter. If this virtual server hasn't been opened, the function should fail.

Note that a virtual server name has no relation to some physical server name. Take this example:

(nntp "odd-one" (nntp-address "ifi.uio.no") (nntp-port-number 4324))

Here the virtual server name is `odd-one' while the name of the physical server is `ifi.uio.no'.

The back ends should be able to switch between several virtual servers. The standard back ends implement this by keeping an alist of virtual server environments that they pull down/push up when needed.

There are two groups of interface functions: required functions, which must be present, and optional functions, which Gnus will always check for presence before attempting to call 'em.

All these functions are expected to return data in the buffer nntp-server-buffer (` *nntpd*'), which is somewhat unfortunately named, but we'll have to live with it. When I talk about resulting data, I always refer to the data in that buffer. When I talk about return value, I talk about the function value returned by the function call. Functions that fail should return nil as the return value.

Some back ends could be said to be server-forming back ends, and some might be said not to be. The latter are back ends that generally only operate on one group at a time, and have no concept of "server" -- they have a group, and they deliver info on that group and nothing more.

In the examples and definitions I will refer to the imaginary back end nnchoke.

10.6.2.1 Required Back End Functions		Functions that must be implemented.
10.6.2.2 Optional Back End Functions		Functions that need not be implemented.
10.6.2.3 Error Messaging		How to get messages and report errors.
10.6.2.4 Writing New Back Ends		Extending old back ends.
10.6.2.5 Hooking New Back Ends Into Gnus		What has to be done on the Gnus end.
10.6.2.6 Mail-like Back Ends		Some tips on mail back ends.