Re: Debugging extremely long IMAP folder exit times

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Jason L Tibbitts III <tibbs@math.uh.edu> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> 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.