Re: [Nmh-workers] IMAP/nmh, again

[Bakul Shah]

On Thu, 26 Oct 2017 17:26:37 -0400 address@hidden wrote:
address@hidden writes:
> 
> On Thu, 26 Oct 2017 13:18:05 -0700, Bakul Shah said:
> 
> > The trickier aspect, and the real issue for me, is proper
> > synchronization when email is accessed from multiple machines,
> > and which may not be connected all the time. On reconnection
> > a client has to upload its changes and resync its local cache
> > with the imap server so that changes made elsewhere are
> > properly reflected.
> 
> AIUI, the big issue has always been that nmh has expected message numbers
> to remain static until explicitly changed (i.e.  message 35 *stays* message 35
> until 'folder -pack' or something changes it), while IMAP message numbers
> can change even during a connection, so UUID's need to be used instead,
> which means keeping a message<->uuid mapping someplace.

Indeed.  Keeping such mapping is what I planned to do. folder
-pack only changes the local msgID<->UID map so no need to
talk to the server for that. But as UIDs are assigned by the
imap server, after a refile there will be messages with no UID
(at least temporarily).

I should really clean up my design notes and post them here...

> And making that robust under concurrent access sounds even worse...

Luckily this is taken care of by various imap extensions as
the problem exists even for "pure" imap clients. But I have a
feeling we will discover more corner cases + imap server
implementations that don't quite do the right thing.