Page 1 of 1

sg object model

PostPosted: Thu Sep 02, 2004 12:46 am
by josh
We've talked about this before, but one thing I'd like to nail down for refactoring is an object model. Currently, we have:

spameater.pl -- main [procedural] routine

Config.pm -- holds config data and db connections
Util.pm -- various utility methods
CommandLineMailer.pm -- a "mailer" class that handles sending the mail

there are some others that are used for web stuff, but that's a topic for another evening.

and it looks like Amit made one MBoxParser.pm - header parsing.


The goal is, of course, to move as much logic as practicable out of the main routine, without overdoing it to the point where performance suffers. Where we're using 3d party code, our implementations can wrap theirs.

To start with, I was thinking about a Message.pm that would set up shop with a new message (and call the xxParser.pm) and provide accessor methods to get sender, recipient(s), etc. -- these could come out as arrays of Address.pm instances. Probably the only recipient addresses we care about are spamgourmet addresses, so maybe we just have SpamgourmetAddress.pm, which has accessors for the constituent parts.

Then we'd need a decision maker class that would take in the message (or just the address) and make the go/no-go decision -- maybe it's the one that calls the xxMailer.pm

is this making sense?

PostPosted: Thu Sep 02, 2004 2:26 am
by SysKoll
Josh,

It makes sense. Can you please detail the plans you have for replacing the current design? Currently, we spawn a new spameater with its Perl process for each message. I believe that's the largest performance issue by far. You mentioned Milter plugins for sendmail?

PostPosted: Fri Sep 03, 2004 11:19 pm
by maratheamit
Josh, I second your idea. As we change over to this new design it would be nice to also develop some regression/unit tests for the various classes: in particular, the decision making class.