From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/73272 Path: news.gmane.org!not-for-mail From: James Cloos Newsgroups: gmane.emacs.gnus.general Subject: Re: fast list Date: Mon, 18 Oct 2010 19:17:09 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1287443967 20693 80.91.229.12 (18 Oct 2010 23:19:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Oct 2010 23:19:27 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M21644@lists.math.uh.edu Tue Oct 19 01:19:26 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P7yzG-0006nx-2E for ding-account@gmane.org; Tue, 19 Oct 2010 01:19:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1P7yzB-0001qI-9V; Mon, 18 Oct 2010 18:19:21 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P7yz9-0001q1-PJ for ding@lists.math.uh.edu; Mon, 18 Oct 2010 18:19:19 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P7yz5-0006xa-4G for ding@lists.math.uh.edu; Mon, 18 Oct 2010 18:19:19 -0500 Original-Received: from eagle.jhcloos.com ([207.210.242.212]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P7yz4-00083t-00 for ; Tue, 19 Oct 2010 01:19:14 +0200 Original-Received: by eagle.jhcloos.com (Postfix, from userid 10) id BED41401E5; Mon, 18 Oct 2010 23:18:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1287443946; bh=fJf9MM85/PFKHveLKBtSQJVLIHXEepQDfG6mmHKwCzE=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=d9n7t5RguJ8aTglX4dD0t2X+KwhxW9Ye/ea7B+zw1YM1ivBx+cu8ikJIYuudNds6o Juw8DY28CzgR+0zOZPku345NHVOuX4Tw5BtutLXpZNtipw9PdC7U7FpysNNSFn2Z8Y +PCBukToSvoZtro2QZ11MURjNeoweWDG5rR/LL9Q= Original-Received: from carbon.jhcloos.org (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 9A7EC1E7A3D for ; Mon, 18 Oct 2010 23:17:09 +0000 (UTC) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 18 Oct 2010 23:03:16 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Original-Lines: 51 X-Hashcash: 1:30:101018:ding@gnus.org::7H8RXveNPb8EKfm2:000Xwd8R X-Spam-Score: -2.0 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:73272 Archived-At: >>>>> "LMI" == Lars Magne Ingebrigtsen writes: LMI> Well, if you issue FETCH FLAGS, then you have to issue EXAMINE, too. LMI> Returning the FLAGS for all the groups will be so much data that's it's LMI> not generally useful. Why not? It is what gnus does now, just one group at a time instead of all in one go. LMI> However, a global QRESYNC would be excellent. QRESYNC works by LMI> outputting all the flags that have changed since . So if LMI> you said LMI> LIST "" "%" RETURN (STATUS QRESYNC 43488328) LMI> (or something) to return all the changed flags since that sequence LMI> number, that would allow a really fast and comprehensive LMI> server->client flag sync-up. True, but adding QRESYNC requires adding CONDSTORE, and the latter is a big project. I'd expect several days to get it right. LMI> Have a look at RFC5162 for the QRESYNC description, but there it's only LMI> a parameter to EXAMINE/SELECT, so you still need to EXAMINE all the mail LMI> boxes, annoyingly enough. Yeah, we'd need to do an i-d to register another extended list option. LMI> But here's a thought: nnimap could have a "sloppy" mode. In the sloppy LMI> mode, it doesn't care about syncing flags that comprehensively, and LMI> instead deferring that to when you enter the group. The sloppy mode LMI> could work with the LIST RETURN command, for instance, or an EXAMINE run LMI> (with no FETCH FLAGS). It would just look at UNSEEN and UIDNEXT, and LMI> just say "if UNSEEN is 5, and UIDNEXT is 242, then we say that all LMI> messages between 1-236 are read, and the last five are unread". When LMI> the group is entered, it issues a "FETCH FLAGS" and gets things right. LMI> But this could be result in pretty brittle behaviour if everything isn't LMI> done just right... That would be closer to the way other clients tend to work, I'd imagine. If it did that for startup and g, then M-g could continue to work like now. The equivilent of UID FETCH FLAGS for every group, if done as a single command, takes about one or two seconds, vs 20 minutes iterating through one group at a time. I am eager to fix that. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6