[Mulberry-discuss] Anticipatory header downloadwrote:

[John C Klensin]

--On Tue, 12 May 2015 07:02:02 -0400, Tanstaafl

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

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

...

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

[David Gessel]

I work overseas in places with bad internet: Iraq, Afghanistan, etc. You know, places that are representative of the internet access of the vast, vast majority of the population of the planet.

Dialup is faster in most cases. Latency and bandwidth are highly constrained. In Iraq we have a 2mb link that is shared by about 20 users and about 100 machines. That's ultra-premium access.

When people say that performant optimization for low bandwidth links is increasingly irrelevant it is a quite infuriating manifestation of myopic global ignorance. While revenue generation comes from locations with high bandwidth links, so one would expect commercial operations to deprioritize low bandwidth, the overwhelming majority of the world on the wrong side of the digital divide (including minority neighborhoods in the US, by the way); it isn't something that seems compatible with a non-profit organization dedicated to serving the common good.

One of my great frustrations as a person who connected to servers with 1200 baud modems initially and had perfectly usable tools is the generally flabbergasting ignorance of modern "developers" that can't seem to compile a text editor that doesn't require a gig of RAM and weigh in at 100mb and require a 10mbps link with sub 50msec latency to work right. Because they grew up considering 4G access a "compromise," they're effectively incompetent to develop for the global market.

[Tanstaafl]

I work overseas in places with bad internet: Iraq, Afghanistan, etc. You
know, places that are representative of the internet access of the vast,
vast majority of the population of the planet.

Most of whom will not have much of a clue what IMAP is, much less use
any kind of mail client but a web browser.

I'm not saying you don't have a valid point, but you seem to be trying
to lump all of the above people into a camp that supports your arguments
in favor of such dramatic importance being attached to something that
affects only a very small minority of users in the real world - ie those
who are cursed by unreliable+low bandwidth internet access and want to
use a heavy standalone mail client and are super concerned about
security and not leaving traces of cached mail locally.

[Bill MacAllister]

Post by Tanstaafl

I work overseas in places with bad internet: Iraq, Afghanistan, etc. You
know, places that are representative of the internet access of the vast,
vast majority of the population of the planet.

Most of whom will not have much of a clue what IMAP is, much less use
any kind of mail client but a web browser.
I'm not saying you don't have a valid point, but you seem to be trying
to lump all of the above people into a camp that supports your arguments
in favor of such dramatic importance being attached to something that
affects only a very small minority of users in the real world - ie those
who are cursed by unreliable+low bandwidth internet access and want to
use a heavy standalone mail client and are super concerned about
security and not leaving traces of cached mail locally.

This reminds me of a bit of an Arlo Guthrie song:

Other countries would say "Hey, he's the last guy...screw him", you
know? But in America, there is no discrimination, and there is no
hypocrisy,'cause they'll get anybody. And that's a wonderful thing
about America.

Bill

[Tanstaafl]

Post by John C Klensin
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.

True - but I'd say more 'lucky 90% of the IMAP using world that cares'...

Post by John C Klensin
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.

True - but I don't see the relevancy. In the above case, are you
suggesting that a user could then download, install, configure and use
Mulberry? I highly doubt it. Those kinds of computers are usually
tightly locked down.