On Fri, Feb 06, 2004 at 10:17:42AM -0800, Justin Mason wrote:
> IMO, we *need* to keep compatibility on this.   It's the main API used by
> users of the perl modules, and I've just had to fix a third-party script
> that used it; there's no easy way to support multiple versions of the

Well, that depends ...  How important is backward compatibility to us?
I don't want to change everything around for the fun of it, but I want
to get rid of as much cruft as I can.  For instance, getting rid of the
whole Mail::Audit stuff made "NoMailAudit" unnecessary.

> This is a very nasty thing to do for a public API. :(

Yes and no.  It's a nasty thing to do unless a major release occurs
where APIs are allowed to change.  Hence the whole 3.0 vs 2.7 thing.

> 1. keep NoMailAudit for the name of that module, and its API (preferred!)

We could keep the name, but the API will be different unless we
do a bit of reengineering.  In fact, I don't really think this is
possible. (MsgContainer->NoMailAudit)

> 2. add a NoMailAudit compatibility wrapper class (using the "facade"
> pattern) which is used to wrap Mail::SpamAssassin::MessageParser.

Could do that, but it'll be really annoying, especially since NoMailAudit
will just be around for backwards compatibility with 3rd party modules,
while our code uses the new API.  Not to mention the fact that some stuff
from NoMailAudit just isn't valid anymore (mostly an issue for people
who like to access object variables directly and not through the API.)

There are 2 main issues with the current design that make the old API
break.  1) You call MsgParser and get back a MsgContainer object.  There's
really no point in having a MsgParser object since it's just making a tree
of MsgContainer nodes.  2) M::SA::PerMsgStatus::rewrite_mail() returns a
_NEW_ MsgContainer tree.  The reasons for this are 1) it's cleaner, and 2)
there's really no easy way of recreating the tree from the tree itself.

> Also -- another issue: the naming, MessageParser, is not appropriate
> IMO.  It seems good from our point of view from "inside" the product,

Yeah, whatever.  I picked MsgParser and MsgContainer for lack of
better names at the time.  If we wanted to be accurate, MIME::Parser
and MIME::TreeNode would probably be better.  I don't really like those
either though.  Feel free to come up with new names for those, it's not
hard to change.


I don't have a problem with the API change as long as we continue
"cleaning house" and getting rid of the old baggage that we don't
need/want to keep around.

-- 
Randomly Generated Tagline:
"Running Linux 1.2 Because a 486 is a terrible thing to waste." - Unknown

Attachment: pgp4KpiPEGTwO.pgp
Description: PGP signature

Reply via email to