Dan Karp writes:
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.
The experience I have with this is that people hate it when the client
redownloads, and they also dislike reading both the vfolder and the
backing mailbox. If you try to solve the first problem on its own,
you're optimising for a case people don't want. You're optimising for
minimal traffic from server to client and disregarding the traffic from
screen to eye.
What people mostly want is to see the rest of the messages from the
backing folder, ie. all those which aren't in a specific vfolder. My
suggested solution to that is a new search key, INVFOLDER. (I made a
concrete suggestion for that about five months ago, not sure if I cc'd
Would it make sense to change the draft such that the contents of a
VFOLDER are set at SELECT time?
And add a sentence like this in draft-*-vfolder: "Clients SHOULD send an
UNSELECT/SELECT pair every two minutes if they want to be informed of
That way the server isn't responsible for aging messages in/out due to
WITHIN criteria and it doesn't have to keep adding and removing (and
renumbering) messages if the VFOLDER criteria reference mutable
No, but it gets to do the same work in the guise of SELECT, UNSELECT,
SELECT, UNSELECT, SELECT, UNSELECT (repeat ad infinitum).
lemonade mailing list