> > > Hence draft-cridland-imap-context-00
> 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.
You've got a point. That may indeed be a better solution, as it doesn't
require any UID magic and clients may not view messages that transition from
matching to non-matching state as EXPUNGEs (which would cause re-downloads if
they transition right back to matching).
I think that my main sticking point is client-side, not server-side. Whether
the client always remains sync'ed with the state of a persistent search or it
refreshes only when the user requests it, I'm still a proponent of presenting
the user with static views of search results.
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 under them.
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.
lemonade mailing list