39 lines
1.8 KiB
Plaintext
39 lines
1.8 KiB
Plaintext
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
|
|
|