Re: Anticipatory header download

Tanstaafl:

> If Mulberry is performant with large IMAP mailstores, then I guarantee
> you it is caching things, at least to an extent.

Nup, never seen any evidence of a long-term cache. I could be wrong because I 
haven't looked at the code, but I know where Mulberry stores most of its data 
and there isn't any cache of mail headers. At least excluding fiddling about 
with offline and disconnected modes; I can't speak for that case.

As explained in another reply, Mulberry downloads only the subset it needs for 
the current display, plus a bit extra pre-fetching (configurable). That is 
just kept in memory, not stored. And that's what makes it performant, rather 
than assuming by default that headers for every message in the entire remote 
hierarchy needs pre-fetching and saving. But yes, it means if you close that 
mailbox window, Mulberry will need to fetch those headers again. That was 
pretty efficient even in dialup days, IIRC.

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.


Tanstaafl:

> 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. The 
situation is not helped by some well-documented poor mailing list 
implementations providing headers that result in the wrong default, meaning 
people have to work around that in their clients.


Tanstaafl:

> The bottom line though is, the best thing that could be done for
> performance for a new install/account setup is to download the bare
> minimum of headers in the main thread, then pass the rest to a low
> priority background thread.

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.).

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. 
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.