On 22 Nov 2020, at 13:32, Dianne Skoll via MIMEDefang wrote:
On Sun, 22 Nov 2020 13:24:24 -0500
Dianne Skoll <[email protected]> wrote:
Anyway... I'd really like to see MIMEDefang development activity pick
up again. I'm hoping The McGrail Foundation will attract more
interest in the project.
Specifically... these are things I would do differently if I were
starting MIMEDefang now instead of 20 years ago. :)
The C code is mostly fine; the milter and the multiplexor work
pretty well.
The Perl code is atrocious.
That's a bit harsh...
It is solidly non-OOP and clearly organically grown over a long time,
but I've worked with worse code that was more carefully designed.
mimedefang.pl is over 7500 lines of
Perl in one ugly file with a ton of global variables. It needs a
major
overhaul. I would start by writing a MD::Filter base class
and storing state in the MD::Filter object. Callbacks could be
implemented
as methods and users could subclass MD::Filter to implement their
behaviour.
PLUS: A more elegant design. Probably easier to maintain long-term. More
accessible/attractive to trained developers who are more comfortable
with OOP.
MINUS: Raises the bar for Perl skill needed to implement local
customizations. Less accessible for people who only understand
procedural programming.
Functions like md_check_against_smtp_server, etc. should
be broken out into helper modules.
Yes. Having done some work in and around md_check_against_smtp_server, I
agree that breaking out those sorts of utilities into other modules
apart from the core functionality would be a good idea, even if it's
just into a MD::Utils module full of subroutines.
The actual filter file would be a very simple thing that simply
instantiates a (subclass of) MD::Filter and calls $filter->run() to
run the main mimedefang.pl loop.
Comments/thoughts/etc?
Obviously OOPifying MD would be a v3 project, as it would break all
existing mimedefang-filter.pl scripts.
A nearer-term step to clean up the code a bit would be to break out
existing code to distinct modules that may (or may not) be the basis for
future object structures. This could result in supporting existing
configurations with a code base that is easier to maintain and
understand.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
