[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: why I don't want CCs



On Thu, 17 Jul 2003, Mark Ferlatte wrote:
> Bijan Soleymani said on Thu, Jul 17, 2003 at 02:06:18PM -0400:
> > I really don't see a valid argument for MTA/MDA/MUA on a PC-type
> > one-user workstation. Especially on a laptop. When MUAs support IMAP and
> > POP they should go the extra inch and support SMTP smarthosts.
>  
> I've found a local MTA on a laptop to be wonderful; I can just send mail, and
> let the MTA's queuing mechanism hand off to a smarthost whenever I get
> connectivity.  Saves time on slow/poor connections.

I also find that a local MTA on a laptop is great.  I have a local
network which grabs my email from several sources and sorts it, then
every other machine on the network can access that email via imaps.

My laptop is configured to periodically check to see if it can make
a connection to the server, and, if it can, synchronize the laptop's mail 
directories with the servers (offlineimap).

The end result is that I can take my laptop anywhere, read the messages 
that it grabbed from the server, compose my replies, all without
worrying what network connectivity I have.  Once I get home, I just need 
to plug the laptop into the local network: no logging in or running a 
specific program.

Same with newsgroups - my laptop maintains a small local cache, and I 
read them when I'm on or offline - as soon as I'm back on a network, my 
replies will be sent out.

This collection of several binaries (exim, procmail, courierimap-ssl,
bogofilter, fetchmail, offlineimap, mutt, vim, gnupg, etc) may seem like
a massive PITA just to read and reply to email, and it is harder to
setup then opening Outlook Express, pointing it to a smtp and pop3
server, and entering in a few lines of information.  In exchange for the 
initial difficulty, I gain a modular system that is easy to maintain,
upgrade, and adapt to my needs.  I don't have to find the one true email
client that does all of the above - instead, I can mix and match the
best of breed in each category.  I don't have to have to use the email
client that has a poor mail editor just to get a good spam filter:  I
can continue to use mutt and vim with bogofilter.  Perhaps one day
I'll decide that spamassassin is a lot better then bogofilter, and
switch - but if I do, I don't need to learn anything else: any unix
email client should work with it.  I can jump from mutt to emacs and my
mail sorting and spam filtering will still work.

From the end user perspective, the above might be a bogus argument - 
how many people truly change their email client from day to day?  From a
development perspective, the modularity looks a lot different - I don't
have to trust the mutt developers to be experts in encryption - that's
the gnupg team's responsibility.  The exim guys don't need to worry
about how to inject email from remote systems and deliver it locally -
the fetchmail group has already written a program to grab the email,
rewrite the headers, and feed it to exim for local delivery.  For a
developer, the code becomes simpler, yet, with all the apps taken as a
whole, the end result can have many more features then the typical
windows mail client.  At the same time, by delegating different tasks to
different programs, there is less duplication of effort, and the results
are available to everyone.  If gnupg adds a new feature, or better
optimization, elm and mutt users benefit.  Mutt doesn't need to add 
an editor to itself - it can use vim, and vim doesn't need to add a
spellcheck - its simple to find the plugin that uses ispell or aspell to
do the job.

Unix application modularity may have an abstract elegance, but it also
tends to lead to "smarter" program chains then having one large program.  
Coders don't have to be experts in every aspect of a task - all
they need to know is how to write their code so that other modular
programs (whose coders are experts on that specific task) can work with
their own.

Going back to the end user, we find another bonus - no longer does the
end user need to learn how to do the same task different ways - if the
program is going to need an editor, it can use the editor the end user
is most comfortable with.  Any tricks I learn in vim I can use while
composing messages in mutt or slrn.

Which is why I like Unix/Linux.

Just my (very long) $.02,

Jesse Meyer

-- 
         icq: 34583382 / msn: dasunt@hotmail.com / yim: tsunad

   "We are what we pretend to be, so we must be careful about what we 
    pretend to be." - Kurt Vonnegut Jr : Mother Night

Attachment: pgpQDO4SyACOi.pgp
Description: PGP signature


Reply to: