Re: Anticipatory header downloadwrote:

--On Tue, 12 May 2015 07:02:02 -0400, Tanstaafl
<[email protected]> wrote:

>...
> Interesting, and I understand the argument in context of slow
> internet connections, but in this day and age... well, if this
> is on someone's short list of required features, I doubt TB
> will ever officially support it, since in the modern age, it
> really isn't useful - if you are on a slow connection, just
> use a webmail client.

Apparently you don't end up on slow and metered/expensive
connections in developing countries, using an IMAP computer over
a cellular roaming connections (or its satellite equivalent) and
high cost per megabyte, or dealing with a connection so fragile
that the issue is less the amount of data transferred by whether
you can keep the connection up long enough to transfer it.  If
so, lucky you.   And, btw, for those situations, most webmail
clients are worse than Mulberry if only because their authors
feel a need to make them decorative.

--On Tue, 12 May 2015 08:00:41 -0400 Tanstaafl
<[email protected]>
wrote: 

> I don't really see a value today for anything like the 'kiosk
> mode' you described, so won't go there. I vaguely see the
> argument, but don't think it would be worth the trouble of
> implementing - although, if a caching mechanism is smart
> enough, I guess it would be easy enough to implement.

Sigh.  Consider trying to use a public-user computer in the
lobby or a hotel or one in a pool area within a university.  You
could, of course, use a webmail client instead... if the mail
server administrators were willing to allow one of those given
that _their_ caching, data exposure, and, in many cases,
business models tend to expose a lot of information.

Again, may not be important to you, but different people have
different needs.




--On Tue, 12 May 2015 22:59:59 +1000, Bernie Maier
<[email protected]> wrote:

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

But that is where the distinctions get important and why I
didn't give Mulberry a higher score in my earlier note.   If I
suffer from poor bandwidth and/or high connection or data costs
or fragile connections, I probably want to operate disconnected,
storing only headers of interest and message bodies only for
messages where I need them and only on a per-bodypart basis.
Mulberry does all of that, but, if I look at some header/ TOC
information while online and then want to access them in
disconnected mode, Mulberry requires that they be download again
rather than being able to copy them from a local cache into the
disconnected store.  Similarly, if I look at a given message
body (or body part) while online, then decide I want to work on
it while disconnected, I need to download it again rather than
having it copied from cache.  And, while Mulberry gives me good
control over downloading part of a message by "first body part"
or length, there is no way to select particular body parts for
downloading from later in the message.  I also cannot mark a TOC
entry to specify that the message (or selected parts of it)
should be download after I connect or the next time I disconnect.

I'm actually not complaining about Mulberry in this (and Cyrus
knows about my concerns from much better times).   But, if
anyone is planning to use this list discussion to specify
requests for something else or the design for Mulberry 5.0,
those issues are important too.

    john