On Sat, Jul 28, 2012 at 11:19:25AM +0200, Rado Q wrote:
> > On Wed, Jul 25, 2012 at 10:51:54AM +0200, Fredrik Gustafsson wrote:
> > > Just of curiosity, why are mutt moving away from a mua to a full email
> > > program with mail fetching and mail sending.
> >
> > {...} and because the internet landscape has made it hard for
> > users to run their own services (thank you, spammers).
>
> Using built-in SMTP-client or a standalone SMTP-client doesn't make a
> difference for the ISP, it can't tell what software executes the SMTP.
No, but it makes a difference to the USER. Mutt is already hard to
configure. If you have to configure sendmail to talk SMTP on the MSP
port, enable STARTTLS, pop-before-smtp, etc. you need to learn a lot
about sendmail. No one should need to do that just to be able to send
an e-mail.
> > It's really not reasonable to expect or ask users to be fully
> > knowledgable about setting up and maintaining a full-fledged MTA
> > just so they can send e-mail. It's way out of the scope of most
> > people's needs.
>
> a) Popular distros provide easy to use MTA support.
> b) being totally dumb about how eMail works isn't desirable either. ;)
Sure it is. Most people who use e-mail have no interest in learning
all the ins and outs of how e-mail works. They just want to
communicate effectively with their colleagues/family/etc. I happen to
know a lot about e-mail, since I needed to in order to do my job; but
if that weren't the case, I wouldn't care one bit about how it all
works.
Mutt is a weird case: it's for power users. But you still don't need
to know how MTA works to be an e-mail power user. We have at least a
few of those on this list.
> > {...} but then users need to learn how to configure many different
> > applications with completely different configuration mechansims,
> > instead of just one consistent one. In this day and age, it's too
> > much to ask.
>
> Heh. :)
> Why is it now but worked before?
> Has humankind been dumbed down?
> Should we support this trend? ;)
No! [Well, maybe.] It's because computers and computer science have
been around long enough that this stuff should just work, and be easy.
Sadly, somehow, that's still not the case for e-mail. Some apps do it
better than others, for sure. Really though, some apps do certain
things better than others, and other apps do certain other things
better. Mutt is very powerful, but it is far from the perfect MUA.
> > Computers are meant to work for humans, not the other way around.
>
> Nothing wrong with that, but somebody has to make the computers work.
> Why not everybody for her/himself?
Because it's a pointless waste of time. If the programmer can do it
once, the users don't need to each do it every time... That's exactly
the sort of efficiencies that computers are good at addressing and
should be addressing.
> > But there are times when one giant monolithic application with a
> > simple interface and reasonable defaults really is what you need.
>
> There are enough of this kind around, mutt needs/ed not to become
> another one of them.
Many of us don't agree. Mutt solves a whole class of mail-related
problems that other clients don't solve, or solve poorly; but at the
same time, there are a lot of things that people who use e-mail do
that mutt doesn't handle well. The biggest one IMO is HTML mail...
It's very popular, as it allows people formatting options that are
very useful for written communications. Mutt handles this rather
poorly. Reading HTML mail is clunky, and AFAIK there really are no
good options for generating it with Mutt's tool chain.
Now you can argue that people shouldn't use HTML e-mail, but that
argument is at best outdated... Based on my daily use I would guess
that people who use HTML e-mail are now in the majority, and Mutt's
inability to handle it well is a big weakness. You can say HTML can
be handled by a web browser, and you'd be right -- but that solution
is clunky at best, and if you need to retain formatting for others
later in the thread, you really need another e-mail client.
Also I've brought this up before, and there was a very negative
response from a lot of people, so I expect the same from you... but I
think it bears saying in context of this discussion. This ties into
the comment above, but there are other reasons. Mutt could benefit
greatly from having an *optional* GUI. The fact is GUIs provide a lot
of ease of use that is missing in Mutt. Mutt is (IMO) more powerful
than any other e-mail client, but that power comes at a cost: it's
expensive (in terms of time investment) to learn, and complicated to
configure. A GUI could greatly mitigate that cost... The benefit to
users would be immense; but, given a suitably modular interface
design, and especially since the feature would be optional, the cost
to those who don't want to use it would essentially be nothing. But
anyway, that's really a separate discussion from this one...
> Don't get _me_ wrong: ;)
> I like things to be simple & easy to use, too.
> But within its own area of operation.
Mutt's area of operation is e-mail... are you saying that submission
of e-mail via SMTP is not related to e-mail? =8^) If you take this
philosophy to its extreme, there is no need for Mutt at all; you can
simply tie together all the other pieces together with some shell
scripts! So let's do that... let's disband mutt and instead write
some documentation on how to write shell scripts that tie together
your editor, fetchmail, and an SMTP agent of some sort, all the MIME
handling software, etc.; and let the users all do everything
themselves. That's the ultimate ideal of the Unix philosophy...
This would certainly be the most customizable option!
> I prefer modular solutions to use them as _I_ like them, gives me
> more power, less dependence on fixed or not easily changed features.
And here's the point: All these features are optional. If you don't
want the SMTP support, compile it out. POP? optional. IMAP?
optional. Compile them out. Your mutt stays exactly what it is now.
If you want a small, maximally efficient Mutt, you still get that,
while the people who want that support (and let's be clear, there are
a LOT of them, which is why the support was added in the first place,
after lots and lots of arguing), still get the features they need. If
you exclude these features completely, you still get what you want,
but many other people who want the power of Mutt don't.
And to be honest, the reality is these features are small, and cost
very little, even when they're compiled in. They're pretty modular
and most likely aren't even in memory unless you're using them. And
the impact on code execution is basically zero.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgplfjuxKuQQw.pgp
Description: PGP signature
