From: SunFire <nu...@jb...> - 2005-07-28 00:17:12
|
The IMAP RFC calls this kind of server-> client notifications "unitlateral notification" and you need them to keep the client and the server synchonized. Here the RFC text anonymous wrote : Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages. One of the reasons this needs to be done is that client and server need to be in sync for message sequence number(MSN). But lets talk about a simple case: - mailbox contains 10 messages when connection 1 SELECTs the mailbox - connection 1 NOOPs around for a while since the user just keeps his client open on his workstation - now he also connects his laptop and for some reason opens up connection 2 that SELECTs the same mailbox - he EXPUNGs the mail with MSN 3 on conn 2 - now by IMAP RFC the mailbox is required to reorders it MSNs and decrement all MSN > 3 by 1 after an EXPUNGE and all future references from the clients also need to be aware of the new MSNs - if conn 1 is not notiefied that the number of mails in the mailbox changed and he deletes the same mail on his first client (MSN 3)... the server will happily acknowledge it and delete MSN 3... what happens to be the former MSN 4... *boom* I am no IMAP expert by any means but this MSN reordering thingy is kinda tricky if you don't want to rely on the clients implementation to check for such things or don't want to totaly lock a mailbox as soon as one imap instance uses it with read-write lock. (This is just my interpretation of it so it may also be wrong) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886954#3886954 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3886954 |