Re: Mutt Next Generation
On Thu, 27 Jan 2005 11:00:02 -0500, John Franklin said:
> I want one fewer program to configure to do a basic task: e-mail. I want
> common things to be trivial. I want mutt to manage the passwords.
You need to configure it anyway, whether to do that in muttrc or an
mta-rc doesn't actually matter. Both will need the same information
and mutt might come preconfigure for exaclty that one tool.
> Why? Why should I have to install yet-another-program, deal with the
> password management issues mentioned elsewhere in this thread,
Because it is easier, it reduces complexity, it adds another security
boundary (think SE-Linux), is really easy to reuse, makes testing much
easier, etc.
> well by linking in an SMTP library. No SMTP code would be in mutt per
> se, it would be in the SMTP library.
Putting up everything in libraries is not a good approach and only
dictated by the sheer amount of code GUI tend to have. Designing and
implementing a proper library is far more expensive than writing a
simple tool. Unix systems have one well defined security boundary:
the process; glueing everything into libraries circumvents this.
> Claims of UNIXy are nice, but will that be a consolation when mutt get
> forked? There is a crying need for this feature (see the others on this
It is a need of user not understanding the principles of Unix. If they
don't want that they should use one of the other MUA which have not
been designed with that in mind but what user running Windows are used
too. I don't say that those MUAs are bad; they are just in another
category and designed for different people than for the average Mutt
user.
> The patch is UNIXy in its own way. Mutt is good at managing e-mail.
> libESMTP is good at delivering e-mail to a server. They're
This introduces a lot of library dependencies out of your control: A
short guess: db4, gnutls, gcrypt, ldap. Depending on your
desitribution.
> process, use a library call. The library has function parameters as
> its API. The process has command line options. What's the difference?
There is a huge difference. Keeping the API of a tool compatible is a
well understood task and manageable even by beginners. Keeping a
library API and here also the ABI compatible is a major problem and
not well understood by the majority of developers.
Salam-Shalom,
Werner