On 11 Jul 2003 at 23:26, Cyrus Daboo wrote:
> | I'm sorry to be the bearer of bad news on this. The good news is that
> if | you implement THREAD=REFERENCES and do so correctly (unlike Courier
> which | does not), users of clients that use it will bless you since you
> will | greatly speed up their performance.
>
> Unfortunately I have of late been running more and more into the
> problem of users wanting to THREAD very large mailboxes and
> complaining when it takes a long time. They are not keen on restricting
> the input message set to e.g. just unseen or messages sent within a
> recent period of time. I would strongly urge server implementers to
> look beyond merely caching references headers, and to come up with
> smart caching of the actual thread tree structure itself. Failing that
> clients will have to drop back to doing client-side caching of all the
> data in order to make handling large mailboxes an acceptable experience
> for the user - that kind of defeats the purpose of THREAD in the first
> place.
As Mark pointed out in his reply to me, the addition of a single message
to the store can completely invalidate such a cache; for many message
stores, I suspect that the process of detecting the messages that have
been added to a mailbox since the cache was created is probably an
NlogN problem as well, and that's leaving aside the logistical issues of
dealing with the situation where a non-IMAP client manipulates the
message store between sessions.
This isn't to say that Cyrus's comment isn't valid - it clearly raises an
important issue; it's just to highlight that solving it entails working with
problems that don't necessarily have obvious solutions.
Cheers!
-- David --
------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: [EMAIL PROTECTED]
Phone: +64 3 453-6880 | Fax: +64 3 453-6612
On the menu in a Tokyo restaurant:
"Butered saucepans and fried hormones."
