[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Future directions for nmh

From: Ken Hornstein
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Wed, 16 Mar 2016 20:25:14 -0400

>But this makes it *your* turn to come up with an insane idea.
>Waiting ... 

Well ... okay!  So, honest critique time: you know more about IMAP than
I do.  If you see problems with this, please let me know what they are.

I'm speaking in terms of existing nmh interfaces; presumably they would
be all different if the internal API is redone.

For each IMAP folder, we have a cache file.  It might look like this:

# This is an nmh folder cache file for folder IMAP:gmail/poop
NEXTUID 998765
MSG 1 40861
MSG 2 66934
MSG 3 22851
MSG 4 77993

... and so on.

When an nmh program calls folder_read() (the function to scan a folder and
build the internal folder structure of each message), an IMAP SELECT on the
specified folder is done.  So you'd issue a SELECT gmail/poop (I don't
know if that's a valid folder name).

If your EXISTS, UIDVALIDITY, and NEXTUID values all matched what was stored
in the cache file, you're good!  If you want to look at message 3, you'd
issue a UID FETCH 22851 with what you wanted.

If your UIDVALIDITY did NOT match, then you'd just regenerate the whole
cache file with new message numbers, starting from 1 (since you'd have no
idea which message corresponded to which UID).  Maybe emit a warning in that

If your EXISTS or NEXTUID did not match was you stored, you'd do something
like (I think I have this right, assume there are now 37 messages):

        FETCH 1:37 (UID)

You'd get that list of UIDs and compare them to your cache.  If a UID was
missing from your cache, you'd have a hole in your nmh message numbers;
UIDs that were new would be added right after the highest-numbered nmh
message number.  So let's say you had 3 messages added in the above example
and the message with UID 66934 deleted; nmh message '2' would now be missing,
and there would be new messages 36, 37, and 38.  So, persistent message
numbers on the nmh side which AFAICT is 90% of the problem.  You'd perform
all IMAP operations based on UIDs rather than IMAP message sequence numbers.
Commands like 'folder -pack' and 'sortm' just change the local cache and
would not change the IMAP store.

So ... thoughts?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]