Re: Anticipatory header download

On 5/12/2015 8:59 AM, Bernie Maier <[email protected]> wrote:
> Now I recall from your previous replies that TB can be configured to 
> not pre-fetch headers for the whole remote store, so we don't need to
> repeat that here. I'm just denying your assertion that caching is
> absolutely necessary. Desirable by many, sure, but not necessary.

This would also depend on usage. If you have it configured to only
download a small subset of a very large mailstore (and it would be worse
if this was deleted at the end of every session), and then needed to
search the entire mailstore (I do this frequently), it would either have
to download the headers for the entire mailstore (the first time - or
again every time for each new session if you delete the local cache at
the end of each session), or ignore what is not downloaded and falsely
claim there are no results, or prompt you (let you know that there may
be messages that meet your search criteria that are not in the local cache).

>> Or - does Mulberry not not have a proper 'Reply-To-List' feature So
>> no one has ever complained about this?

> Yes, it does, but it's highly configurable. Some people may have set 
> a default for their own reply-to rules, but I personally prefer to be
> prompted for each reply. Even then I sometimes forget to deselect all
> the unnecessary items.

I prefer to just manually use either CTRL+SHIFT+L (for reply to list) or
CTRL+R (for normal reply), depending on what I want to do. However if
the list is CC'd and I'm trying to reply to list on that copy, reply to
list fails because there are no list headers present in the direct reply
- which, again, is the only one I get because the default for this list
is to enable de-dupe, which means if I am directly CCd on a reply I
never get the list response, which totally breaks reply to list.

> Really, I think for a performant new installation / account it should not 
> bother to pre-fetch anything beyond the bare minimum to display in the mail 
> folder currently being viewed, plus a bit extra for scrolling. And it's not 
> necessarily about paranoia, it's about avoiding premature optimisations that 
> actually slow down performance by downloading data that may never be used 
> (e.g.
> mail headers from my old work email account from 1997). Now maybe TB isn't 
> doing that, I've lost track in these discussions. But that is why I rail 
> against mail clients that do (e.g. Evolution, Apple Mail (I think), etc.).

Yes, it does by default download [a subset of] the headers for all
messages in a folder that you click on, and I agree this definitely
causes a temporary slowdown the first time (which is why I said
everything beyond the first few messages should be downloaded in a low
priority background/secondary thread)...

> But I guess the reality is that most new users (who aren't "power" users, 
> anyway), are willing to sacrifice some performance to have that cache built.

The performance hit only happens the very first time you click on a
folder. After that it is very fast.

> Because they won't have a large enough pre-existing store to worry about it. 
> But that performance hit does bite the power users, which is why some of us 
> are so vigorously defending Mulberry's default approach.

Which begs the unspoken question from my prior email:

What happens if you perform a search on a huge mailstore that only has a
few message headers downloaded? I'm truly curious...