Don't make balsa a like a windows program (was: libfetchmail)

[Edward Betts <edward debian org>]

On balsa-list, Mikael Hermansson <mikeh@bahnhof.se> wrote:
> IMHO! I dont understand this discussions about POP3/IMAP/SMTP.
> That all the people on the list is talking about :-)
> 
> First of all we need to have a good gnomebased mail "reader"
> that have all features as pine/mutt, search functions and other
> important stuff. In the moment balsa bug as hell and is unusabel as
> reader...
> 
> Fetchmail/Sendmail is doing the other things greats as daemons :-)
> 
> When we have a good working mailer then we should start talking about 
> implement POP3/SMTP/IMAP as libs or maybe use gnome-mailer codebase.

I agree completely. The receiving of the mail is not for some GUI client to
handle it is for the mail server and possibly a fetchmail daemon. Yes we could
intergrate the configuration of fetchmail into balsa, but there must be an
option to just leave everything as it is. For sorting of mail procmail is the
best tool in my IMHO, it should be left as the method for sorting mail. Again,
possibly with the ablility with a gnome front-end linked to balsa, and it
should be replacable without upsetting balsa. 

We are building a Unix tool not a MS-Windows tool. 

The Unix tradition = lots of small apps working together to get the job done
The Windows tradition = bloat, fit every function into one program

This is the way mail should go:
Mail fetcher --> Mail server --> Mail sorter --> Mailboxes --> Mail user agent
(fetchmail?)     (exim?)         (procmail?)     (~/Mail/*)    (balsa)

Nice simple standard Unix implementation. If you dislike any of the bits
remove them. You can replace fetchmail with something else, exim with
sendmail, procmail with mailagent, mbox format with maildir format, balsa with
mutt. Each of the components is individual, and can be replaced individually. 

It could be argured that this way of doing it is more complicated and difficult
to set up, but with some gnome frontend config scripts for fetchmail, exim and
procmail it would be easier enough for home users. Maybe use linuxconf or have
a gnome wizard to generate config scripts for every program in the chain. 

Similarly for sending mail, I do not really want my mail program to try and
connect to my smarthost. If I use a windows e-mail client, then the client has
to be open when I connect to the internet, so that I can press the button to
send and receive mail that is the wrong way. It wants to be queued on my mail
server, so I do not need my mua open.

Writing an e-mail:
Mail user agent --> Mail server --> ISP Smarthost
\/  /\  \/  /\
Editor  GPG/PGP

In a windows client everything is handled by the client. The client includes a
POP3 feature to download the mail. Stores it in its own propierty file format
in obscure directory. There is no support for using to mail clients to access
the same mail spool. Sorting is handled by the mail client, stored in the
registry where it is not possible to change it with a text editor, the only
reasonable interface is a GUI, which does not include cut and paste. 

The windows client uses its own editor, so you have to use its keybindings.
When the mail is finished only rarely can it be encryted or signed, and then
in programs like Outlook Express only using Microsofts encryption format, not
PGP, with keys only supplied by one company (Verisign). To send the mail, you
have to bring up the internet connection and connect to the your ISP smarthost
using the same mail client.

IMHO the Unix way is the right way, the MS-Windows way is the wrong way.

-- 
I consume, therefore I am