Re: [VM] Info node "External Messages"

[Alan Wehmann]

What follows are some observations that I've made with the one IMAP
folder that I have been using of late, and speculations on how things
might have been done differently.

First off, I show the Summary buffer for the folder
"fermi_email:inbox":

> ->  1  U    Dick Carrigan     Mar  7   37/5605   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     2       address@hidden  Mar 16   16/2025   "LIBRARY - You borrowed this 
> book"
>     3       Dick Carrigan     Apr  6   91/7806   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     4  D    Mark Messier      Apr  7  137/10825  "Fwd: LBNE Reconfiguration: 
> webpage and workshop (April 25-26)"
>     5       WinZip Computing  Apr  5  293/17469  "Type 3X Faster with Your 
> Voice - 50% Off Dragon"
>     6       Fermilab Today    Apr  6    0/113632  "Fermilab Today - Friday, 
> April 6"
>     7       Fermilab Today    Apr  5    0/218959  "Fermilab Today - Thursday, 
> April 5"
>     8       Fermilab Today    Apr  4    0/133659  "Fermilab Today - 
> Wednesday, April 4"
>     9       Fermilab Service  Apr  8  124/9300   "Please take this survey 
> related to Incident INC000000231795"

As a reminder, I've got "vm-imap-max-message-size" set to 50,000.

I then use function "vm-goto-message" to go to message #6 and the
result is that it is loaded from the IMAP server:

>     1  U    Dick Carrigan     Mar  7   37/5605   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     2       address@hidden  Mar 16   16/2025   "LIBRARY - You borrowed this 
> book"
>     3       Dick Carrigan     Apr  6   91/7806   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     4  D    Mark Messier      Apr  7  137/10825  "Fwd: LBNE Reconfiguration: 
> webpage and workshop (April 25-26)"
>     5       WinZip Computing  Apr  5  293/17469  "Type 3X Faster with Your 
> Voice - 50% Off Dragon"
> ->  6       Fermilab Today    Apr  6 1812/113632  "Fermilab Today - Friday, 
> April 6"
>     7       Fermilab Today    Apr  5    0/218959  "Fermilab Today - Thursday, 
> April 5"
>     8       Fermilab Today    Apr  4    0/133659  "Fermilab Today - 
> Wednesday, April 4"
>     9       Fermilab Service  Apr  8  124/9300   "Please take this survey 
> related to Incident INC000000231795"

I then do "vm-quit" and follow that with "vm-visit-imap-folder" and
re-visit "fermi_email:inbox".  The Summary buffer now indicates that
message 6 has zero lines, once again:

> ->  1  U    Dick Carrigan     Mar  7   37/5605   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     2       address@hidden  Mar 16   16/2025   "LIBRARY - You borrowed this 
> book"
>     3       Dick Carrigan     Apr  6   91/7806   "Next quarterly lunch 
> Wednesday, April 11 [retired scientist list]"
>     4  D    Mark Messier      Apr  7  137/10825  "Fwd: LBNE Reconfiguration: 
> webpage and workshop (April 25-26)"
>     5       WinZip Computing  Apr  5  293/17469  "Type 3X Faster with Your 
> Voice - 50% Off Dragon"
>     6       Fermilab Today    Apr  6    0/113632  "Fermilab Today - Friday, 
> April 6"
>     7       Fermilab Today    Apr  5    0/218959  "Fermilab Today - Thursday, 
> April 5"
>     8       Fermilab Today    Apr  4    0/133659  "Fermilab Today - 
> Wednesday, April 4"
>     9       Fermilab Service  Apr  8  124/9300   "Please take this survey 
> related to Incident INC000000231795"

It isn't hard to examine the "fermi_email:inbox" folder and see that
the headers for message #6 are present, but that the body of the
message isn't there.

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?  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).  It
seems to me that if the headers only could be presented (for a large
message), there wouldn't be any circumstances under which to ask the
interactive questions about loading the full message or about deleting
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?

Cheers,
Alan

Uday Reddy writes:
 > To: address@hidden
 > Subject: Re: [VM] Info node "External Messages"
 > Date: Sun, 8 Apr 2012 10:44:46 +0100
 > From: Uday Reddy <address@hidden>
 > 
 > Alan Wehmann writes:
 > 
 > > I can emphasize the following conclusions from this evidence:
 > > 
 > > 1) Thunderbird is synchronizing a file on my computer's hard drive,
 > > matching the contents of the IMAP inbox folder.
 > 
 > Yes, indeed, it does!  VM's IMAP folders work the same way too.  But what
 > shape the cache folders are in, before you force a full synchronization in
 > some way, are internal decisions for Thunderbird as well as VM.  They are
 > not meant to be portable across different mail tools.
 > 
 > (Note that Thunderbird also keeps essential information about the folder in
 > .msf files.  The format of those files is again internal to Thunderbird.  If
 > you make any changes to a Thunderbird folder inside VM, VM will delete the
 > .msf file.  For Local Folders, that is perfectly fine.  Thunderbird can
 > reconstruct the .msf file from the folder itself.  For IMAP cache folders,
 > deleting the .msf file can result in loss of information for Thunderbird.
 > So messing with Thunderbird's cache folders inside VM is not recommended.)
 > 
 > > 2) The setting of 50000 for "vm-imap-max-message-size" is working.
 > > Messages in excess of that size are having only their headers
 > > downloaded, when "vm-get-new-mail" is used.  The full message is
 > > downloaded if I choose it in the Summary buffer.
 > 
 > That is good.
 > 
 > > 3) It is possible to have VM parse the Thunderbird synchronization
 > > file (local on my hard drive), but it involves a bit of trickery.
 > 
 > Covered in my response to (1).
 > 
 > > My experience on April 4 (when I was using the IMAP inbox folder as a
 > > spool file), of being asked a) if I wanted to download each large file
 > > (answer no), and then being asked b) if I wanted to delete it from the
 > > "maildrop" (answer yes . . . bad choice, bad choice, bad choice) has
 > > me wondering about the design of those questions.  It seems to me
 > > rather odd to ask me if I want to delete a large message if I haven't
 > > even looked at it (with VM).
 > 
 > That was Kyle Jones's design.  I guess the idea must have been that, if you
 > don't want to download a message from the server due to its size, then it
 > would be sitting on the server for ever and ever, filling up disk space.
 > So, there must be a way to get rid of it.  Looking through the CHANGES file,
 > this has been there probably since VM 6.14 (February 1997), first for POP
 > then adapted to IMAP (July 1998).  In those days, mail servers were meant
 > for delivering email, and you were expected to download the email as quickly
 > as possible and delete it from the server.  So, it made sense.
 > 
 > POP folders were implemented in December 2001.  "External messages" (headers
 > downloading) was planned but never done.  Here is a thread on vm.info
 > archives which indicates the plan:
 > 
 > https://groups.google.com/forum/?fromgroups#!searchin/gnu.emacs.vm.info/pop$20max$20message$20size/gnu.emacs.vm.info/17qDHuWoIqc/HiuVa_FoIfgJ
 > 
 > (Look for Terry W.'s message on 2/21/2002 and Kyle's responses.)
 > 
 > Now that we have external messages implemented, that is the preferred way of
 > reading IMAP mail.  We should regard the idea of IMAP spool files as a
 > historical relic that is out-of-date and to be avoided at all costs.
 > 
 > Cheers,
 > Uday
 > .

-- 
Alan Wehmann
address@hidden