--
On Wed, Jun 12, 2002 at 07:03:55PM +0100, David Woodhouse wrote:
| mb@??? said:
| > >> In fact, this would be nice for the various lookups and mailstore
| > >> formats too. Packages could provide a base exim with the rest as
| > >> separate add-on modules loadable at runtime.
| > >
| > >Left as an exercise for the reader.
| >
| > I don't know if such modifications would make it into Philip's Exim,
| > though. I quite like the argument "if you can't build an MTA, you
| > shouldn't be admin of one"--just think of the extra noise on a list
| > such as this should Red Hat offer packages for exim, exim-mysql,
| > exim-maildir..
|
| I can't see the point in it for exim-maildir. Perhaps for stuff like
| ldap, perl or mysql though -- things that if built-in require other support
| libraries and perhaps would prevent the Exim binary from running or the
| package from installing in their absence. If those modules were shipped as
| dynamic shared objects, Exim could try to load them but cope gracefully if
| the libraries which they require are not present.
|
| You don't actually have to ship the extra modules in separate packages. But
| yes -- that perhaps wants a little more thought
Putting the modules in separate packages (as debian, though not rh,
tends to do) allows the dependencies of the packages to be really well
thought-out and allows an admin to not install the mysql (or whatever)
client libraries if they don't want them, and allows another admin to
very easily install it for his system.
| and might not want to get incorporated into Exim proper, as it's
| definitely a distribution issue.
Certainly the packaging itself is a distribution issue, but the code
to dynamically load the modules isn't. I think it would be a good
idea (maybe patches coming later, no promises yet) to include a
compile-time option like the linux kernel does for modules.
| > Otoh I do like the local_scan being a dynamic shared object: it "would
| > be nice" to be able to plug more than one such object into an Exim, so
| > that you have lots of small bits of obviously correct code--maybe one
| > for your virus scanner, one for SpamAssassin, one for
| > some-sort-of-PGP-validator, etc--and you can just chain them together.
|
| Yeah -- being able to load more than one local_scan function and call them
| in the order specified un{til,less} one fails would perhaps be a useful
| feature. It shouldn't be that hard to extend the code I hacked up to do
| that.
|
| Again, left as an exercise...
One alternative is to create a chained_local_scan.so to do this, which
would be loaded by the local_scan you (David) created. The
flexibility of this is really cool!
| We may want to consider changing stuff around so an Exim daemon would load
| the local_scan libraries first, rather than _every_ child having to do so
| upon receiving its first message. OTOH, we may not want to bother -- I
| don't really know how expensive dlopen() is.
Then again, if the child is going to quit before running local_scan()
(eg if a callback arrives with no data, or a host is rejected before
data is sent) then it might be better to have latent loading. I think
the best approach is to have people (besides just me, my system won't
notice the difference) test it and measure the differences.
-D
--
He who scorns instruction will pay for it,
but he who respects a command is rewarded.
Proverbs 13:13
Jabber ID : dman@???
GnuPG key :
http://dman.ddts.net/~dman/public_key.gpg
--
[ Content of type application/pgp-signature deleted ]
--
