From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/62942 Path: news.gmane.org!not-for-mail From: "Ted Zlatanov" Newsgroups: gmane.emacs.gnus.general Subject: Re: downloading attachments on demand Date: 19 Apr 2006 14:40:07 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <4nwtdl2yuw.fsf@asimov.bwh.harvard.edu> References: <29acarvoxa.fsf@james.hut.fi> <871wvvtf6k.fsf@latte.josefsson.org> <4nmzei7hu9.fsf@asimov.bwh.harvard.edu> <87hd4qziqv.fsf@latte.josefsson.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145472271 32754 80.91.229.2 (19 Apr 2006 18:44:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2006 18:44:31 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+m11469@lists.math.uh.edu Wed Apr 19 20:44:26 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FWHez-0007o2-4L for ding-account@gmane.org; Wed, 19 Apr 2006 20:44:17 +0200 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 1FWHei-0000H3-00; Wed, 19 Apr 2006 13:44:00 -0500 Original-Received: from nas02.math.uh.edu ([129.7.128.40]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1FWHaF-0000Gv-00 for ding@lists.math.uh.edu; Wed, 19 Apr 2006 13:39:23 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas02.math.uh.edu with esmtp (Exim 4.52) id 1FWHaC-00062U-68 for ding@lists.math.uh.edu; Wed, 19 Apr 2006 13:39:23 -0500 Original-Received: from clifford.bwh.harvard.edu ([134.174.9.41] helo=mail.bwh.harvard.edu) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1FWHa0-00057v-00 for ; Wed, 19 Apr 2006 20:39:08 +0200 Original-Received: (qmail 981 invoked from network); 19 Apr 2006 18:31:38 -0000 Envelope-Sender: tzz@lifelogs.com Envelope-Recipients: jas@extundo.com, ding@gnus.org, Original-Received: from asimov.bwh.harvard.edu ([134.174.54.119]) (envelope-sender ) by mail.bwh.harvard.edu (qmail-ldap-1.03) with SMTP for ; 19 Apr 2006 18:31:38 -0000 Mail-Followup-To: "Simon Josefsson" , ding@gnus.org Original-To: "Simon Josefsson" X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" In-Reply-To: <87hd4qziqv.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 18 Apr 2006 23:17:12 +0200") User-Agent: Gnus/5.110005 (No Gnus v0.5) Emacs/22.0.50 (gnu/linux) X-Spam-Score: -2.6 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:62942 Archived-At: On 18 Apr 2006, jas@extundo.com wrote: > "Ted Zlatanov" writes: > >> On 18 Apr 2006, jas@extundo.com wrote: >> >>> Alternatively, as I believe I have proposed before, we could add a >>> new backend interface to allow Gnus to query the MIME structure of >>> articles, and then only request partial articles, and handle the >>> Gnus cache coherency stuff in Gnus instead of in some >>> nnimap-specific command. >> >> Can we combine this work with the flags work we discussed a while ago >> (arbitrary flags/tags)? > > I don't see much connection, actually. How would you combine these > two things? I don't mean they are directly connected, but that they both require a rethinking of the backend API. If they both require it, it's better to do a major change like that just once. >> It would probably be easier to do a major backend addition like that >> in one effort instead of twice. > > Adding a backend interface isn't that difficult. I mean the backend API. It should change to allow body structure queries and arbitrary tags. I don't think in its current form it can do either easily, but perhaps I'm wrong. >> It may also be worthwhile to look at the entire nn* backend system and >> how it's implemented in each backend. I'm sure there are lessons to >> be learned and code that could be rewritten for better performance or >> reliability. > > Yup. This, too, could require significant changes... So I would suggest combining all that work in one project instead of spreading the pain and knowledge over several projects. Ted