SiteMap Search ElispArea HowTo Glossary RecentChanges News Problems Suggestions

ViewMailHeadersOnly

Last edit

Changed:

< This solution involves significant re-engineering of VM.

to

> The solution of '''Fetch''' buffers involves significant re-engineering of VM.


Headers-only messages in a VM folder have only their headers stored in the folder. The bodies of the messages are stored somewhere externally and fetched on demand.

Motivation

The purpose of the headers-only operation is to allow:

Background

It is sometimes said that VM does not have a “folder API” [2], that is to say that it does not keep a separate index file through which remote folders can be accessed. This rules out the use of IMAP and maildir mail stores. When pressed, Kyle Jones said [3]:

The main reason is that no one seemed to want them, and it would be some trouble to implement. The people who want a directory that contains thousands of files seem to have abandoned monolithic mailers like VM a long time ago.

Maildir certain[ly] wins on updates. But as is typical of systems that are write friendly, it loses on reads. It also loses on searches unless you have a very good index. VM, being a mail reader, does much more reading and searching than writing, so I think optimizing for reads is a better choice.

Headers-only messages provide a partial solution to this problem.

Idea

An experimental method for headers-only operation was devised by Robert Fenk when he was an active maintainer of ViewMail. Normally, VM stores email mesasges in a Folder buffer. It generates a Presentation buffer when needed to display individual message bodies. Robert’s idea is summarized in three points:

Advantages

  1. Folders can have a mixture of headers-only messages and full messages. (So, for instance, one can have recent messages in full and older messages in headers-only mode.)
  2. Only the needed message bodies are fetched and they are immediately discarded when the user moves to another message. No special action is needed to discard the message bodies.

Disadvantages

  1. Since the message bodies are not cached, they need to be fetched every time a message is viewed.
  2. For MIME messages, the Presentation buffer often displays only buttons for attachments. The message body needs to be fetched each time one of the attachments is opened.
  3. If one cycles through the MIME display states using the ‘D’ command (‘vm-decode-mime-message’), each step of ‘D’ requires the message body to be fetched again.

Implementation

The problems 2 and 3 can be solved in principle by maintaining a separate Fetch buffer in which a single message body is maintained. But this is delicate because most of VM code expects the body to be found in the Folder buffer.

The experimental implementation of these ideas is planned for VM 8.2.0 and its prereleases. Initially, there will be no Fetch buffer. Instead VM will provide operations ‘vm-load-message’ (and ‘vm-unload-message’) through which message bodies can be loaded into (respectively, unloaded from) the Folder buffer.

It will not be possible to open attachments without loading a message body into the Folder buffer. As far as possible, VM will load messages automatically whenever needed. The user will be responsible for unloading them if necessary. Both of these commands can operate on marked messages. So they can be executed in bulk.

The solution of Fetch buffers involves significant re-engineering of VM.

VM tends to assume that there is a single buffer that a message is associated with and the identity of this buffer is stored in a slot in the message descriptor (‘vm-buffer-of’). The data about the message as well as the message body are obtained from this buffer.

On the other hand, for a headers-only message, we would like to use the Fetch buffer for the message body and the Folder buffer for the standard data. Separating the two roles involves checking every use of ‘vm-buffer-of’ in VM (there about 100 such uses), and making sure that the right buffer is used.


ViewMail; ViewMailWishlist