Re: [VM] Info node "External Messages"

[Uday Reddy]

Alan Wehmann writes:

> This leads me to ask the speculative question of why wasn't the design
> decision made to have the Presentation buffer show the header
> information for a large message--without fetching the body, and then
> letting the user decide whether or not to fetch the body, based upon
> the header contents?  

The original motivation for "external messages" mechanism (also called
"headers-only messages" during their inception) was to allow VM folders to
be small.  Some people get megabytes to gigabytes of email on a monthly
basis, and keeping all of it in an Emacs buffer is impractical.  Some people
also use gmail with practically infinite mail folders and downloading all of
it into an Emacs buffer is also impractical.

Reducing the *initial* download-time was also a motivation, because Emacs is
basically locked up while it is downloading messages.  (Note that
Thunderbird doesn't have the second problem, because it is written in a
language with concurrent threads.  We will have to wait for Emacs Lisp to
develop concurrent threads to implement something similar for VM.)  

I knew that Rob F had this on his To-Do list, and it now appears that Kyle
Jones had it on his To-Do list too.  Neither of them got around to doing it.
It was a major task to implement them, because it required a careful
re-engineering of almost all of VM.

Avoiding the downloading of *individual messages* wasn't particularly on my
mind.  The wait-time there is not significant, at least in my experience,
and I also think it is quite rare for people to want to delete a message
without even looking at it.  But it is on the To-Do list and I might spend
some time on it depending on how important it turns out to be.  (Note that
Thunderbird doesn't have such a feature.  It downloads a message as soon as
you want to view it.)

It could be more important to avoid downloading attachments.  That way, you
can download the basic text of the message and decide to delete it.  This is
also on the To-Do list, but it requires significant amount of new coding to
query and parse the MIME structure of messages from the IMAP server.  So, it
will only get done when I get a large block of free time.

> Any decision the user wishes to make about
> deleting the message--based upon the header contents--could be made at
> this point also, rather than the interactive question that asks him
> about deleting the message even if he hasn't seen the header
> information (with IMAP folders, it is not clear to me the
> circumstances under which he would be asked the interactive questions
> about downloading a large message and if he wishes to delete it--as I
> experienced when using the IMAP inbox folder as a spool file).  

There are no interactive questions with IMAP folders.

It is possible to delete the message without viewing it, but it requires
some planning on the part of the user.  In typical usage, the users will
tend to view the message before deleting it, and that requires downloading
the message.  (The same answer as to the previous question.)

> it.  Does the design choice that was made have something to do with
> whether or not the server has the capability to provide only the
> headers of the message?

No, the server capability is not an issue.  All IMAP and POP servers have
the capability to provide the headers if we ask for them.  The issue is more
of how to organize the internals of VM so that it can deal with a message
without the body in the first instance, then download the body, and
recalculate everything.  (There are some dark corners in VM here in terms of
how VM interacts with the Emacs display engine.  I don't fully understand
how it works and doing it wrong can cause "jumping cursor" problems.  Rob
F's 8.1.x branch had many such problems, and I applied some "vodoo" here and
there to make them go away without really understanding why they were
happening.  See revisions 565, 544.1.22, 544.1.31, 647, 969.1.2 in the
trunk.  So, some things which appear to be simple on the surface actually
turn out to be hard.)

Cheers,
Uday