On 21 January 2002, Kevin P. Fleming said:
> I'd like to use perl for these functions, but this leaves me with two
> options:
>
> 1) implement a standard local_scan file that includes an embedded perl
> interpreter, then use external perl scripts to do the work
> 2) use Exim's built-in embedded perl interpreter, and extend its use to
> allow a local_scan function to be called (in addition to using "${perl"
> constructs in string expansions)
>
> Option 2 seems far more efficient to me, but there are couple of issues I'd
> like to get answers to before I proceed down this road:
>
> - Would Philip be willing to accept patches (tested, of course :-) to add
> this functionality to Exim 4? I'm thinking this would be an additional
> compile-time option, just like embedding perl is now. The local_scan
> function would get passed some perl data structures (using Mail::Internet
> and other existing modules) that contain all the message information.
IMHO, it would be better to just pass the message to the Perl
interpreter as text (or an open filehandle, or whatever), and let it
parse the message itself. What if someone doesn't want to use the
standard way of working with email messages? Some applications will
care about the headers only, some will want headers+body -- let the
external code make that choice. Yes, make the standard way easy, but
don't force it on anyone.
In a related note, has anyone whipped up the code to link in a *Python*
interpreter via local_scan()? That's my current high-level language of
choice...
Greg
--
Greg Ward - software developer gward@???
MEMS Exchange http://www.mems-exchange.org
