From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52159 Path: main.gmane.org!not-for-mail From: Zack Weinberg Newsgroups: gmane.emacs.gnus.general Subject: IMAP partial fetch (was Re: Ideas for .no Gnus) Date: Fri, 02 May 2003 17:12:15 -0700 Sender: ding-owner@lists.math.uh.edu Message-ID: <874r4ckhwg.fsf@egil.codesourcery.com> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1051920706 26117 80.91.224.249 (3 May 2003 00:11:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 3 May 2003 00:11:46 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M702@lists.math.uh.edu Sat May 03 02:11:45 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Bkcy-0006n5-00 for ; Sat, 03 May 2003 02:11:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19Bkde-0003jM-00; Fri, 02 May 2003 19:12:26 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19BkdZ-0003jH-00 for ding@lists.math.uh.edu; Fri, 02 May 2003 19:12:21 -0500 Original-Received: (qmail 60076 invoked by alias); 3 May 2003 00:12:20 -0000 Original-Received: (qmail 60071 invoked from network); 3 May 2003 00:12:20 -0000 Original-Received: from egil.codesourcery.com (mail@66.92.14.122) by sclp3.sclp.com with SMTP; 3 May 2003 00:12:20 -0000 Original-Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 19BkdT-0003NV-00; Fri, 02 May 2003 17:12:15 -0700 Original-To: replies@Frank-Schmitt.net In-Reply-To: (Frank Schmitt's message of "Fri, 02 May 2003 23:22:11 +0200") User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52159 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52159 Frank Schmitt 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