From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/88691 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Debugging extremely long IMAP folder exit times Date: Mon, 22 Jul 2019 16:25:54 -0700 Message-ID: <87v9vt648t.fsf@ericabrahamsen.net> References: <87muhb5bk0.fsf@igel.home> <87zhl66jl3.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="148151"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+M36895@lists.math.uh.edu Tue Jul 23 01:26:54 2019 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hphhl-000cMi-RY for ding-account@gmane.org; Tue, 23 Jul 2019 01:26:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92) (envelope-from ) id 1hphh8-00026h-Vq; Mon, 22 Jul 2019 18:26:15 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hphh2-00023y-Rm for ding@lists.math.uh.edu; Mon, 22 Jul 2019 18:26:08 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hphh1-0007qe-7k for ding@lists.math.uh.edu; Mon, 22 Jul 2019 18:26:08 -0500 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226] helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hphgx-0002k1-Hq for ding@gnus.org; Tue, 23 Jul 2019 01:26:05 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hphgx-000bad-A6 for ding@gnus.org; Tue, 23 Jul 2019 01:26:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:zjHHTyjlMFeTSdw9H7Wr0E6gXd8= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:88691 Archived-At: Jason L Tibbitts III writes: >>>>>> "EA" == Eric Abrahamsen writes: > > EA> Ticked is equivalent to IMAP flagged, so that data would also be > EA> preserved in the server, and wouldn't need to be backed up (I > EA> think). > > I would think so, but when I did this Gnus lost track of which messages > I had read and (in IMAP at least) that's also server-side state. So I > really have no idea what might be preserved after a cal to > gnus-group-clear-data. The documentation does imply that it clears all > marks, so I figured it actively cleared everything on the server as > well. Oh, I guess you're right, it removes marks from the backend as well. In the past I think I've "dealt with" this by shutting down Gnus, going into my newsrc.eld, completely removing the entry for the imap group, and then restarting Gnus and re-subscribing to the group. > EA> In theory, Gnus doesn't really need to keep marks that are > EA> redundant to server flags in the first place, but that would take > EA> some tweaking. > > Yes, I don't think the original design anticipated having another entity > which could keep track of all mailbox state. Nope, but it would be nice if it could deal with that. > As an aside, I wonder how difficult it would be to support what will be > rfc8621 (JMAP-Mail). It's certainly a good bit simpler than IMAP in > some ways. The fact that it supports sending mail (just have a message > stored somewhere on the server and provide a request to send it along > with some metadata) is a rather different paradigm from the current way > it's all set up. > > My guess it that it needs quite a bit of work by people smarter/better > at elisp than I am but maybe someone's already playing with it. I don't think anyone is, but it's definitely been in the back of my mind when thinking about refactoring Gnus' backends. It would be fun to have Gnus be the first client outside of Fastmail's own software to support JMAP. It looks like they've just published the first RFC for the storage part of JMAP, but not yet the mail-related part. I've thought about creating light connections between messages under composition and Gnus servers, so that the server itself could have a chance to handle the message -- that would be useful for per-server message drafts, but could also handle server's like JMAP that do the sending themselves. > EA> It would also be nice to know how your 'unexist flags got out of > EA> whack to begin with. > > I honestly have no idea. I do generally have more than one IMAP client > connected to the server at once, but I was only using one of them within > a few hours of this one folder becoming slow. This also isn't the first > time I've had the issue, but it's the first time in a few months. Who knows... I access imap accounts from two Gnus installations and one k9 android app, and nothing's ever gone wonky. Bit of a mystery.