On Thu, 26 Oct 2017 17:26:37 -0400 valdis.kletnieks@vt.edu wrote:
valdis.kletnieks@vt.edu 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
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers