Philip Hazel writes:
> On 14 Oct 1998, Adrian Phillips wrote:
>
> > >>>>> "Malcolm" == Malcolm Beattie <mbeattie@???> writes:
> > Malcolm> If anyone can think of any real applications, I'd be
> > Malcolm> interested (and only slightly surprised). I'd imagine a
> > Malcolm> perl transport (which let you do fancy things and
> > Malcolm> "deliver" a message in the context of exim itself) may be
> > Malcolm> the most likely perl driver to be of use. Or maybe a
> > Malcolm> generic Perl code "lookup" thing (${lookup {key} perl
> > Malcolm> {some_perl_sub} {arg}}).
>
> It seems to me that the simplest generic thing would be the lookup
> thing. You could in fact use that with smartuser to do almost all the
> things your perl director does, couldn't you? (Except for FORCEFAIL. But
> smartuser can be extended...)
I came to that conclusion myself last night--that lookup would likely
be more useful. Nigel Metheringham has pointed out that having an
embedded perl available in filter would be another good thing.
> Another possiblility would be to add a ${perl: operator to the expansion
> syntax, so that any expanded string anywhere could call Perl. This would
> make the "condition" option unbelievably flexible, for a start.
I'll look into that. Doesn't sound hard.
> Is a Perl transport very different from piping the message to a Perl
> script?
Whenever I pipe messages out of an MTA or a printing system into a
separate program, I always find that there's not enough flexibility
for passing information back. The recent thread on sysexits.h is
related to that. If you get some way through processing a message or
print file and then want to say "oops, it turns out I can't complete
processing this properly, please feed it back into this queue/spool
area and notify the user/sender as follows..." then you're SOL.
With an embedded perl transport, it may turn out to be easier to feed
back information to exim (or query it for information) whilst
message transport/processing is happening.
> Anyway, I will take a look at the patch "in due course" (my usual
> cop-out :-) and think about whether I want to incorporate any of it in
> the distribution. It could always be done with a compile-time option, to
> include it only if wanted.
I wouldn't bother looking at at for possible inclusion. I'll make a
nicer version with lookup first. In particular, I think I'll shift
out the startup stuff into a global section as
perl_startup = ...
and maybe
perl_delayed_startup = ...
which delays creating the perl interprter until it's needed. That'll
mean there's no perl CPU overhead in the general case until you hit
a driver that actually needs to use perl. Those worried about memory
footprint can always use that and a shared libperl.so. Then the only
overhead is a single mmap() and maybe some symbol table trickery.
Finally, a documentation suggestion: I spent a fair while wondering
why the perl_director_options table I'd written was ignoring one of
the entries. I finally guessed that the options have to be in
alphabetical order and that seemed to fix it. It might be worth
mentioning in the "Adding new drivers..." chapter. Apart from that,
there was enough information in the chapter to get me started
without trouble.
--Malcolm
--
Malcolm Beattie <mbeattie@???>
Unix Systems Programmer
Oxford University Computing Services
--
*** Exim information can be found at
http://www.exim.org/ ***
