[Imap-uw] Simultaneous access to imap mailbox?

[Mark Crispin]

On Sun, 16 Sep 2007, John Kelly wrote:
> If I do:
> STORE 1:10000 +FLAGS.SILENT (\Seen)
> is that what you mean by "10,000 single message updates,"

No.  That is an aggregate update, and is faster in mix than in mbx.

> or are you
> talking about 10,000 client iterations of the STORE command, one for
> each message?

Yes.  In other words:
 	tag STORE 1 +FLAGS.SILENT (\Seen)
 	tag STORE 2 +FLAGS.SILENT (\Seen)
 	tag STORE 3 +FLAGS.SILENT (\Seen)
 		...
 	tag STORE 10000 +FLAGS.SILENT (\Seen)
is quite a bit slower in mix than mbx.

> I'm just wondering if some clients iterate successive STORE commands
> for each message to be marked, and if a more efficiently coded client
> can avoid the performance issue you mention.

Correct.

Note as well that a client which wants to do POP3-style "download and keep 
on server" is better off doing:
 	tag FETCH 1:* BODY.PEEK[]
 	tag STORE 1:* +FLAGS (\Seen)
than the otherwise equivalent:
 	tag FETCH 1:* RFC822
since in the latter case the implicit set of \Seen is done as the message 
is fetched instead of aggregated.

Similarly, POP3-style "download and delete" is better done doing:
 	tag FETCH 1:* BODY.PEEK[]
 	tag STORE 1:* +FLAGS (\Seen \Deleted)

The worst possible thing is to do:
 	tag FETCH 1 RFC822
 	tag STORE 1 +FLAGS (\Deleted)
 	tag FETCH 2 RFC822
 	tag STORE 2 +FLAGS (\Deleted)
 	tag FETCH 3 RFC822
 	tag STORE 3 +FLAGS (\Deleted)
 		...
since not only doesn't this aggregate anything but also has two RTTs per 
message.

Note that all this applies even with mbx or traditional UNIX format.  It's 
just that doing lots of flag changes with mix will punish you worse.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.