From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59943 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: fetch only a portion of an article? (nnimap mainly) Date: Fri, 04 Mar 2005 23:51:06 +0100 Message-ID: References: <4nfyzbi3yo.fsf@lifelogs.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109976868 21516 80.91.229.2 (4 Mar 2005 22:54:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2005 22:54:28 +0000 (UTC) Original-X-From: ding-owner+M8484@lists.math.uh.edu Fri Mar 04 23:54:28 2005 Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by ciao.gmane.org with esmtp (Exim 4.43) id 1D7LcW-0006Sm-Gt for ding-account@gmane.org; Fri, 04 Mar 2005 23:50:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1D7Le9-0001J5-00; Fri, 04 Mar 2005 16:51:49 -0600 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1D7Le0-0001Ix-00 for ding@lists.math.uh.edu; Fri, 04 Mar 2005 16:51:40 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by util2.math.uh.edu with esmtp (Exim 4.30) id 1D7Ldx-00049M-RR for ding@lists.math.uh.edu; Fri, 04 Mar 2005 16:51:38 -0600 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1D7Ldw-0006h9-00 for ; Fri, 04 Mar 2005 23:51:36 +0100 Original-Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.3/8.13.3/Debian-6) with ESMTP id j24MpLX6008295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Mar 2005 23:51:23 +0100 Original-To: "Ding Mailing List" OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050304:ding@gnus.org::Fqi2zHH8qgVIg82Q:7AXk In-Reply-To: <4nfyzbi3yo.fsf@lifelogs.com> (Ted Zlatanov's message of "4 Mar 2005 14:52:15 -0500") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux) X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yxa-iv X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -4.9 (----) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu X-MailScanner-From: ding-owner+m8484@lists.math.uh.edu X-MailScanner-To: ding-account@gmane.org Xref: main.gmane.org gmane.emacs.gnus.general:59943 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59943 "Ted Zlatanov" writes: > In Gnus, you call gnus-request-article to get an article. What if you > know you only need the first N lines (or bytes)? Can nnimap.el > support that? I can change the gnus-request-article function to > accomodate such an option, and it will be passed to > nnimap-request-article. I just don't know enough about the IMAP > protocol to implement it. > > I need this specifically for nnimap interactions, but I'm sure it can > be implemented for other backends as well. It's useful, for instance, > when summarizing something about the contents of the article, but you > don't want to fetch more than N lines of it. I would use it to > summarize qmail bounce reports - right now, I have to fetch the whole > article just because I need to see what's in the first 10 lines. IMAP support partial retrieval (byte counts), and even retrieval based on the selected MIME structures (i.e., retrieve entire message except one big attachment). I think the problem may be in designing the back end interface properly, so it is flexible enough. Ideally there should be some way to retrieve the MIME structure of an article, and then make Gnus chose which MIME parts to retrieve. But having a line count may be sufficient as a start. However, there is a big problem with caching. If an incomplete article ends up in the asynchronous pre-fetcher, agent cache, user cache, etc, it will require some tinkering to invalidate that copy and force a re-query on the entire article.