On Sun Nov 19 00:04:08 2006, Dan Karp wrote:
> > I've been reading the most recent VFOLDER draft, and it looks >
> pretty good. By making the VFOLDER explicitly a view onto
another > > folder, the message UIDs line up and so a
VFOLDER-capable client > > can correlate (and hence not
re-download) messages in the VFOLDER > > with messages in the
> > As you say, this is only in the case where a virtual mailbox is
> defined using purely static criteria, or, as per your suggestion,
we > "fix" dynamic criteria to be static - and even in this latter
case > I'm unclear if we could rely on UIDs being the same, since
UIDs must > strictly increase - you can't UNEXPUNGE, even when the
client isn't > looking.
Well... In fact, I think current proposals prevent selection of
virtual mailboxes by naïve clients anyway. (Which is their main
advantage, IMHO, removed).
Well, there are ways around that. If the client is VFOLDER-aware
and does something like
C: A005 SELECT (VFOLDER) "unread msgs"
S: * LIST (\Subscribed) "/" "unread msgs" (VFOLDER (INBOX
S: * OK [UIDVALIDITY 3857529045] new uidvalidity each time
vfolder is selected
you can change the UIDVALIDITY each time the VFOLDER is SELECTed,
as the client knows about the backing store folder. (You'd want to
send along an LIST-EXTENDED-style unsolicited response to make
absolutely sure the client knows.)
Or you could simply not return a UIDNEXT value on the VFOLDER and
effectively do an "UNEXPUNGE" while the client's not looking.
Clients are built defensively enough that introducing a new message
whose UID isn't the highest in the mailbox will still work. (It's
my secret shame -- trust me on this.) You'd still be abiding by
the defining rule for UIDs:
But then you're going be to breaking the mailbox semantics. (And
trust me, there are clients for which reintroducing UIDs will break
them. I believe my client is not the only one.) Removing UIDNEXT
*and* removing strictly increasing UIDs is just a pain.
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever.
If you're going to break mailbox semantics, you might as well do away
with them entirely.
> Hence draft-cridland-imap-context-00
> > In this proposal, searches may be made to be dynamically
updated - > the server doesn't add or remove messages from a
mailbox, instead it > adds and removes results from a SEARCH. This
means that UIDs stay > constant, and because no SELECT takes place
at all, the client is > never in danger of double-download.
This definitely solves some of the problems, but I'm not convinced
it's significantly better than the client just doing a SEARCH and
then using notifications to manage the results client-side. But
I'm definitely open to convincing.
Well, it's better in as much as it's a hell of a lot easier to do,
and it can be used with SORT, which client-side emulation can't.
Also, there's quite some difficulty with trying to manage this
without doing a SEARCH command per notification - in many cases, the
client simply doesn't have sufficient data, which introduces
additional round-trips *and* additional transmission data.
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
lemonade mailing list