On Thu, Jan 27, 2005 at 06:09:08PM +0100, Werner Koch wrote:
> 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 exactly that one tool.
I'd rather be in fewer config files, rather than more.
> > 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
The library is already written. The cost of creation has been paid. The
patch is even written.
> simple tool. Unix systems have one well defined security boundary:
> the process; glueing everything into libraries circumvents this.
What do you secure by calling a separate binary to deliver the mail?
What's being protected? Do you think libesmtp is going to pollute
mutt's data space in some way that ssmtp would prevent?
> > 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
You're referring to the Rule of Modularity: "Write simple parts connected
by clean interfaces." (http://www.faqs.org/docs/artu/ch01s06.html)
I would argue that libraries are as good a module as programs.
Programs have the advantage of using a shell and pipe to string
together multiple tools to achieve a result. Here, a shared library
is quite sufficient.
> 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.
And mutt-ng will be one of them, all over a medium-sized, yet
still pretty simple patch [1] that includes support for conditional
compilation into the program.
Mutt shouldn't make this a point of pride. It can't win anything
by doing so.
> > 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.
It adds exactly one library dependency on FC3: libpthread. [2] Two
if you count libesmtp.so itself.
> > 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.
Command line flag incompatibilities and missing applications cannot be
checked at either compile or load time. Library API/ABIs can.
Library ABIs don't (typically) break within a major version number.
Statically linking the application eliminates all shared library
incompatibilities, of course.
API/ABI changes are a programming nuisance, not a major problem. No one
would use shared libraries if managing them were such an issue. Mutt
already does it with thirteen shared libraries. Really, we've got a
handle on it.
New programs can change their command line arguments as easily as new
libraries can change their APIs. Neither do so without good reason,
and usually with a major number bump.
> Salam-Shalom,
>
Cheers,
jf
[1] Medium sized patch, most of it being mutt_libesmtp.[ch].
[franklin@artie:/home/franklin]% diffstat Desktop/patch-1.5.3.sde.libesmtp.3
Makefile.am | 6 -
configure.in | 13 +++
globals.h | 6 +
init.h | 37 ++++++++-
m4/libesmtp.m4 | 63 +++++++++++++++
main.c | 6 +
mutt_libesmtp.c | 228 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mutt_libesmtp.h | 10 ++
protos.h | 2
send.c | 2
sendlib.c | 21 ++++-
11 files changed, 387 insertions(+), 7 deletions(-)
[2] System is Fedora Core 3.
[franklin@artie:/home/franklin]% ldd /usr/lib/libesmtp.so
libssl.so.4 => /lib/libssl.so.4 (0x00760000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x00424000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x001a7000)
libdl.so.2 => /lib/libdl.so.2 (0x00826000)
libc.so.6 => /lib/tls/libc.so.6 (0x001b9000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00111000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00125000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x0018a000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00aad000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0018d000)
libz.so.1 => /usr/lib/libz.so.1 (0x002e3000)
/lib/ld-linux.so.2 (0x00375000)
[franklin@artie:/home/franklin]% ldd /usr/bin/mutt
libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x00a22000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x003c8000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00520000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00faa000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x0032a000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00111000)
libssl.so.4 => /lib/libssl.so.4 (0x00392000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x0012e000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00216000)
libc.so.6 => /lib/tls/libc.so.6 (0x003dc000)
libdl.so.2 => /lib/libdl.so.2 (0x00125000)
libz.so.1 => /usr/lib/libz.so.1 (0x00638000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x007e2000)
/lib/ld-linux.so.2 (0x00686000)
[franklin@artie:/home/franklin]% mutt -v
Mutt 1.4.1i (2003-03-19)
Copyright (C) 1996-2002 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
jf
--
John Franklin
franklin@xxxxxxxxx
ICBM: N37 12'54", W80 27'14" Z+2100'
Attachment:
pgpxuoHuSgE0u.pgp
Description: PGP signature