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

Re: [lemonade] VFOLDER and mutable fields/WITHIN

Subject: Re: [lemonade] VFOLDER and mutable fields/WITHIN
From: Dan Karp
Date: Sun, 19 Nov 2006 10:45:57 -0800 PST
> > > 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
lemonade@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/lemonade

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