At 04:47 2005-11-06 +0100, Ruud H.G. van Tol wrote:
I don't agree. The PCRE can be dynamically loaded on first request, like
by a commandline parameter, or by not having a ~/.procmailrc but a
~/.procmailrc4, or by having a special procmail_PCRE binary, etc. The
default procmail should not basically have to change.
I'm certain that some time ago, I posted some ideas I'd been bouncing
around in my head about LOADABLE procmail extensions. Things to implement
an internal sed or formail for instance. Take the hit for loading the
module ONCE (like, when it was going to be used ANYWAY), and then from
there on out, it would be treated as an internal syntax. It could be
extended to PCRE, MIME, whatever. Obviously some "re-engineering" of some
existing external tools would be necessary (the evil "duplication of
effort), but it would make procmail extensible and maintain a lightweight
core tool.
IMO, if people want to bring the tool into the 21st century (AD), runtime
extensibility is key.
Look at Perl or C and C++. Over the years, they've changed. They've
remained MOSTLY backward compatible (in that old code will compile under
the newer tools), but in some cases, bad habits were frowned upon: newer C
implementations don't like non-prototyped functions for instance. Fact is,
for anything all that complex, one can't expect to drop ancient code into a
new compiler and get it to compile without throwing a few warnings or
errors, and requiring at least a little bit of massaging these days.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail