IMAP partial fetch (was Re: Ideas for .no Gnus)

[Zack Weinberg <zack@codesourcery.com>]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Hello
>
> Now that Oort is released, I'd like to throw some ideas in, which
> features I as (primarily) a user would like to see in the next Gnus:
...

This is the first of my two wishes:

Consider the following imap-log extract (word-wrapped, CRs removed,
and censored):

59 UID FETCH 1:150 (UID
                    RFC822.SIZE
                    BODY
                    BODY.PEEK[HEADER.FIELDS
                     (Subject From Date Message-Id References
                      In-Reply-To Xref To Newsgroups)])

# ... 149 other responses ...

* 150 FETCH (UID 150 RFC822.SIZE 351157 BODY 
             (("text" "plain" 
               ("charset" "us-ascii" "format" "flowed") NIL NIL "8bit" 647 20)
              ("application" "msword"
               ("name" "xxxxxx.doc" "x-mac-type" "42494E41"
                "x-mac-creator" "4D535744") NIL NIL "base64" 348914)
              "mixed")
      BODY[HEADER.FIELDS 
            ("Subject" "From" "Date" "Message-Id" "References"
             "In-Reply-To" "Xref" "To" "Newsgroups")]
      {253}
Message-Id: ...
Date: ...
To: ...
From: ...
Subject: ...

)
59 OK FETCH completed.
60 UID FETCH 150 BODY.PEEK[]
* 150 FETCH (UID 150 BODY[] {351157}

# ... 351157 bytes of message body here ...

The server provided Gnus enough information to know that the message
was multipart, and the second part was a large binary attachment
(application/msword, 348914 bytes).  Yet Gnus downloaded the entire
message body.  I would like Gnus to use the IMAP partial-content-
request functionality to avoid downloading undisplayed attachments
until the user asks for them with the button commands.  In this case,
issuing

60 UID FETCH 150 (BODY.PEEK[HEADER] BODY.PEEK[1])

would have resulted in a transmission of only 1837 bytes of literal
data (1190 for BODY[HEADER], 647 for BODY[1]).  I suspect that this is
a major reason why Gnus is so slow to display articles in IMAP groups
with attachments.  In the case of the message above, I didn't bother
looking at the attachment, so Gnus need not have downloaded it at all;
for messages where the user does want to look at the attachment, they
are probably more willing to accept a lengthy download delay when they
ask for the attachment to be saved, than when they ask to view the
message.

The IMAP4 BODYSTRUCTURE request will reveal the Content-Disposition
annotation for attachments, if any, which may help decide whether or
not to download them.

zw