MBOX-Line: From guenther+imap at sendmail.com  Fri Jul  6 21:43:49 2007
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] \Recent and multi-accessed mailboxes
In-Reply-To: <935361765.24151183780846496.JavaMail.root@dogfood.zimbra.com>
References: <935361765.24151183780846496.JavaMail.root@dogfood.zimbra.com>
Message-ID: <Pine.BSO.4.64.0707062217220.4344@vanye.mho.net>

On Fri, 6 Jul 2007, Dan Karp wrote:
> If there are 2 read-write sessions active on a mailbox to which a new 
> message is added, one receives the message with \Recent set and one 
> receives it without.  If there is 1 read-only session and 1 read-write 
> session on the mailbox, is the server permitted to return the message as 
> \Recent to both?

Yes.  If the read-only session wins the race to be notified first, then 
both sessions will see the message as \recent.  If the read-write session 
wins the race, then it'll be the only one to see it as \recent.

I don't think there's anything to say that a server can't 'notify' a 
client by inserting an EXISTS (and possibly RECENT) placeholder into its 
output buffer but not actually sending it until it has received a command 
from the client.  The ordering between sessions of server-side actions 
such as these are often unobservable by clients, so a client can't depend 
on a particular ordering.  A server that *always* 'notified' all the 
read-only sessions before any read-write sessions would be odd (why 
bother?**) but presumably compliant.


Philip Guenther


** Hmm.  The read-only sessions could then represent the \recent flag with 
a single unchanging number (the UID of the first \recent message) instead 
of needing a bitmap.  Nah: having completely different code for read-only 
sessions would be a pessimization instead of an optimization

