On Sun Nov 19 18:45:57 2006, Dan Karp wrote:
We've got a product that's fundamentally search-based, and
representing searches on dynamic attributes has been one of the
more vexing issues. We've found that people would rather run a
search once and then work their way through a static snapshot of
the result set than have the results vary in real time with changes
in the backing store. Your mileage may vary, but our users seemed
put off when anything other than a real "delete" caused search
results to disappear from their view, or when anything other than
newly-deposited mail caused new search results to appear. They'd
rather explicitly re-run the search than have it change out from
Yes, I get annoyed when I'm using a SEARCH based on UNSEEN, such that
messages would vanish as I read them. So I instruct the client, by a
checkbox, not to dynamically remove messages from the display which
cease to match. It can be done client-side, even with CONTEXTs.
On the other hand, I always want to see messages which become
matching, whether due to delivery or changes in circumstance.
So I'm fine with a protocol that always keeps the client up to
date, and I'm equally fine with a protocol that refreshes a client
view only when the user revisits a "saved search". I just think
that a protocol that EXPUNGEs when a message no longer fits the
search criteria will lead to bad user experience.
One aspect of virtual mailboxes is that should a message cease to
match, it not only vanishes in a way that's indistinguishable from
the message being EXPUNGEd, but also it vanishes in such a way that
it's no longer accessible. In other words, the client cannot choose
the behaviour above. This is particularly annoying if the client
relies on the implicit \Seen flag setting behaviour of a non-PEEK
FETCH, but might actually be frustrating with WITHIN, too.
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
lemonade mailing list