Re: Mutt Next Generation
On Thu, 27 Jan 2005 15:53:13 -0500, John Franklin said:
> I'd rather be in fewer config files, rather than more.
Let that new MSA grep through ./muttrc ;-)
> The library is already written. The cost of creation has been paid. The
> patch is even written.
Fine, so write a simple sendmail similar tool using that library.
Tha's actually waht esmtpd does.
> 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?
The process is a kernel guaranteed security boundary. A simple
example to get the idea: for certain tasks it might be required to
change the uid; thus the tool needs to be run as setuid(whatever) - do
you want the entire mutt process to run this way?
> I would argue that libraries are as good a module as programs.
Libraries have different properties than a program. See above.
> It adds exactly one library dependency on FC3: libpthread. [2] Two
> if you count libesmtp.so itself.
Look closer: what are the dependencies of libesmtp?
BTW, using pthreads is yet another story which changes the internals
of a programm entirely - nothing will be anymore as it has been.
Although linking to a proper written pthreads library from a program
not aware of it will work in most cases; over short or long you will
fall into a trap.
> Command line flag incompatibilities and missing applications cannot be
> checked at either compile or load time. Library API/ABIs can.
You can't check an ABI at compile time.
> Library ABIs don't (typically) break within a major version number.
Huh? That's in fact the usual reason to change the major version
number (well you need to change only the SO-name 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
It is hard to design and keep a stable ABI and API - ask the glibc
maintainers. However, this is not the question. DSOs are good at many
places but they are not the silver bullet of code reuse. In
particular sending out a message won't suffer from any noticeable
performance penalty if it has to do a fork/exec.
Shalom-Salam,
Werner