http://bugzilla.spamassassin.org/show_bug.cgi?id=4497
Summary: reorganise PerMsgStatus code
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P5
Component: Libraries
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
talking about this at the hackathon and there's pretty unanimous agreement that
PerMsgStatus does too many different things.
So here are the conceptual blocks of functionality in PerMsgStatus, and the
proposed new classes to implement it:
- context of scan --\
results of scan ----> Mail::SpamAssassin::PerMsgStatus
(keep this where it is, badly named or not.)
- logic for check() ......> Mail::SpamAssassin::Plugin::Check.
(a new plugin to implement check logic, so that it can be swapped
out for alternative check prioritisation implementations, short-circuiting
implementations, etc.)
- body formats / rendering -\
- URI list --------------------> Mail::SpamAssassin::Message::Rendered
(a new object to hold rendered state off Message. *NOT* Message itself, as
this object has a ptr to {main} and {conf}, so can use configuration data
during its work; it's also deleted when Maill::SpamAssassin::PerMsgStatus
is deleted.)
- logic for each rule type --\
- rule compilation ------------> Mail::SpamAssassin::Scanner
- config parsing for rules --/
- rewrite .....................> Mail::SpamAssassin::Plugin::Rewrite
(a plugin that implements rewriting of mails, so that alternative
rewriting methods can be used instead, optionally)
Regarding backwards compatibility -- all public APIs remain compatible.
This is essential (but easily done).
Every public member variable remains on PerMsgStatus; every public method keeps
a public facade method on PerMsgStatus that just calls into the real
implementation code.
this is post-3.1.0, just wanted to get this into bits and off the whiteboard...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
