lemonade@ietf.org
[Top] [All Lists]

Re: [lemonade] VFOLDER and mutable fields/WITHIN

Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN
From: Dave Cridland
Date: Sun, 19 Nov 2006 11:37:53 +0000
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 backing folder. > > 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, 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 "UNSEEN")) S: * OK [UIDVALIDITY 3857529045] new uidvalidity each time vfolder is selected
   S: ...

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.)


Well... In fact, I think current proposals prevent selection of virtual mailboxes by naïve clients anyway. (Which is their main advantage, IMHO, removed).


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:

   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.


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.

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.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/lemonade

<Prev in Thread] Current Thread [Next in Thread>