Re: Anticipatory header download

--On  Wed, 13 May 2015 12:08:11 -0400 Tanstaafl
<[email protected]> wrote:

> On 5/12/2015 1:16 PM, John C Klensin wrote:
>> 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'...

And I'd say ...   No, actually I wouldn't, because I've learned
to be polite on public lists, even when provoked.

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

No, I'm suggesting that kind of environment was the original
design motivation and environment for IMAP and that one cannot
understand a number of things about how IMAP works and is
intended to work without understanding that sort of environment.
Yes, it implies that the IMAP client needs to be preinstalled on
those "tightly locked down" machines but that is where we get,
as a community, to a fork in the road.

In one last attempt to explain this to you, let me describe my
current environment.  Right now, I'm sitting in a gigabit LAN
environment with the mail server (delivery SMTP, mailstore, and
IMAP server) on the same LAN as my desktop client machine.  The
latter has more than enough horsepower, memory, etc., than it
needs for any possible MUA environment.  It also has somewhat
more than a 1/3 of a square meter of screen real estate.  There
is a good case to be made that the best mail client for me is
some descendant of MH -- IMAP is just extra complexity and
overhead and there is no possible reason for me to mess with
offline or disconnected mode.  Curiously, that same environment
makes a good case for an MUA that uses classic POP3 because
downloading all the mail to the client machine and keeping it
exclusively there works find too -- just a choice of where one
wants the long-term mail storage.

Perhaps unfortunately, I also travel and I travel in two
different ways.  One is to places where the machine at the other
end is fairly similar to the machine here (even if it were a
"portable desktop"-scale laptop rather than a big fixed desktop
machine) and I've got a reliable connection and bandwidth
available to the server in at least tens of megabits.  This is
where IMAP comes in, just as it comes in on a university campus
where one might use a machine in a pool or kiosk as well as the
one in one's office, because IMAP (classical version) eliminates
the need to deal with "now which machine is the best copy of
that message on".  In general, there is still no need for
anything but online mode.  In the other, I end up in places much
more similar to those that David and I tried to describe: poor
connections, limited and/or costly bandwidth, and/or
intermittent availability of the network.  There I start needing
the ability to handle messages locally, to be selective about
downloads, to work on shared devices and/or things that I can
carry around without strain on my arms or back, etc.  And that
handling has to be efficient and take good advantage of local
resources, caching, and the ability to cleaning resynchronize.

And, despite the differences in machines and resources, I prefer
to be using the same MUA interface in all of them, for no more
complex reason than that switching MUAs costs me a lot of
efficiency and makes me crazy.

Those differing requirements and the three-way contrast more or
less summarizes the motivation for IMAP and the changes between
the original version and contemporary (at least pre-Lemonade)
IMAP4.

However, it puts us up against a business problem: most of the
world doesn't care.  They either operate in your "lucky 90%
environment", don't handle very much email at least that is
important, and, perhaps as a result, just don't care.  For most
of them, Webmail is plenty adequate.  For most of the rest,
Outlook is just fine and they have MSOffice installed anyway.
The result is that there is [almost?] no market for a
professionally-developed and maintained email client that is
optimized for people with heavy mail loads, needs in at least
two and often all three of those operational environments.
When those mail loads involve professional traffic with needs
for security management and handling of potentially-sensitive
information, rather than family notes to grandmother, the market
gets smaller and the requirements more difficult.  The result is
where we are: wide use of Webmail, wide use of Outlook (whose
IMAP support is fairly terrible), Mulberry still getting the
"all IMAP clients suck, Mulberry sucks less" designation years
after Cyrusoft self-destructed and active development and
maintenance stopped, and a few well-intentioned open source
efforts like Thunderbird floating around that have largely been
designed and developed by people who (at least from the
symptoms) don't understand the design issues and the reasons for
them (and who, as Bill pointed out in a different way, tend to
be a little dismissive of users whose needs and circumstances
they don't understand and/or appreciate (as you sometimes seem
to be).

The "fork in the road" comment is that I see two possible
futures.  In one, we are on a downhill slope that just keeps
going in that direction.  Mulberry will sooner or later become
unusable, not because there is anything wrong with it but
because environments and requirements will change and it won't
keep up.   In the other, we go through another iteration of the
cycle between localized and highly distributed computing on the
one hand and the big, centrally-managed computing facility on
the other (there is a lot less difference in terms of
operational and trust relationships between "big central
computer center" and "put everything in the cloud" than many
people assume) and some of that "next billion" Internet users
conclude that a messaging environment that lends itself to
complete sentence and even paragraphs rather highly-interactive
exchanges of sentence fragments.   If and when that happens, I
expect to start seeing good, well-designed and supported,
IMAP-based MUAs again.   All I can tell you right now is that
I'm working on it.

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

Again, those kinds of needs and arguments (without some of your
exaggerations) are what motivated IMAP.  If none of them apply,
IMAP is a sort of interesting, but not particularly
well-optimized, way to address a different set of problems
including, in some cases, the interactions between a Webmail
server and a mailstore.

    john