Am 06.08.2014 um 12:15 schrieb Greg Sullivan:
Jochen, I don't have any in-depth knowledge of the IMAP protocol. I'm just saying that given that IMAP is designed for concurrent access from multiple clients, I would have expected it to behave much better when more than one person attempts to move a message, that's all. I was gobsmacked when I discovered that duplicates could easily occur!
Quote from the IMAP wikipedia page: Internet Message Access Protocol (IMAP) is a protocol for e-mail retrieval and storage developed by Mark Crispin in 1986 at Stanford University as an alternative to POP. IMAP unlike POP, specifically allows multiple clients simultaneously connected to the same mailbox, and through flags stored on the server, different clients accessing the same mailbox at the same or different times can detect state changes made by other clients.
that's the theory
"can detect" -> when and how in case of concurrency things are not that easy because you have anyways network latency as part of the game
On 6 August 2014 04:00, Jochen Bern Jochen.Bern@linworks.de wrote:
On -10.01.-28163 20:59, Greg Sullivan wrote:
I must say I am extremely disappointed that intra-account moves are not atomic. As far as I can tell, IMAP was designed to allow shared access, so in my opinion this operation should be atomic. Heaven FORBID that I should ask for entire conversation moves to be atomic as well. (which is really what I want)
How would it be of any use to the passive client that the *operation* is atomic when (as far as I can see, which admittedly mightn't be much) there is no way defined in the IMAP protocol to atomically *notify* it of said change?
IMAP IDLE, for example, may inform it that one message disappeared from mailbox X and one popped up in mailbox Y - not that these two are actually the same message, still have the same set of flags set, etc.. That's for the client to find out by specific requests - which already breaks the atomicity and allows for a race condition between clients.