Toen wij Professional Software Engineering kietelden, kwam er dit uit:
I'm beginning to think I really should investigate what is involved with
adding plugin functionality to procmail.
I am missing that since I met procmail. I have created very specific
modules for PHP (and Apache) in C and that was quite easy to do.
INCLUDEMODULE=some_program_or_library_file FUNCTIONNAME FUNCTIONNAME2
[...] A basic module could be
produced with a variety of standard functions.
[...]
As to backward compatibility, the INCLUDEMODULE line would be ignored
and emitted as a syntax warning in the logfile on older procmails,
which would continue parsing the rcfile, and since the invocation of
the functions
would be generally indistinguishable from program invocations, those
would either correspond to progs the user had (and COULD have instead
of a
plugin), or they'd get an error because the program wasn't found. Thus,
we've got pretty stable backward compatibility with no significant
issues.
It wouldn't even give a syntax warning if it were required to
enclose the full string in dquotes. Otherwise it could unset
variables...
INCLUDEMODULE = "some_program_or_library_file FUNCTIONNAME FUNCTIONNAME2"
will just give a variable a value in unenhanced procmails.
Some issues that spring to mind include forking a copy of procmail and
inheriting the plugged modules, as well as contending with modules which
for one reason or another might opt to retain static data (how are these
dealt with in the event of a fork?), such as preloaded index files, or a
cache of previous lookups on something.
The static data needs to be per-process. A fork starts with a full copy
of the current static data, that is rolled back to a safe point.
Besides being loaded into memory and having the ability to run multiple
operations without involving multiple processes, a plugged module
_could_ conceivably have access to the procmail variable table, where
it could say, create multiple variables based on some action, rather
than needing to
return a long string which would need to be parsed into pieces longhand
in the procmailrc.
Modules should be able to use specific module-functions, see the
'developing
custom PHP extensions' specs: http://www.zend.com/zend/api.php
A perl-module would be nice...
This, and the potential for statefullness (static
variables) between invocations during the same procmail session would
make the pluggable modules dramatically different than what you get in
the
current program exec model - implementing them would of course mean that
one couldn't merely have a functionally equivalent program stub for
older procmails to invoke, because those wouldn't be able to tweak the
procmail variables. This I don't envision to be a big problem - the
added variable-access and optional stateful functionality would be
beneficial,
and people really aught to upgrade their mail tools once in a while. <g>
Yes, that will all be possible with modules.
MIME handling stands out as one potential thorn which could be clipped
with a good procmail plugin, and yet it keeps the MIME code _OUT_ of
procmail - if you don't need it, it isn't there bulking procmail up and
slowing it down.
MIME is just one of the simpler things. <g>
Thoughts anyone?
Yes.
--
Grtz, Ruud
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail