On Thu, 26 Oct 2017 17:26:37 -0400 [email protected] wrote: [email protected] 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. _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
