-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Duncan Findlay writes: > On Wed, Jan 21, 2004 at 10:55:10PM +0100, Malte S. Stretz wrote: > > Nooo, please not that name. Everytime I read something like 'MsgParser' or > > 'PerMsgStatus' I am reminded of this [1] posting on the KMail list ;-) Hrm, > > seriously: I don't think we need/should use Prefixes like 'Msg' to group > > stuff, it's better to use. That's what they're made for and its also more > > shell-completion freindly (currently one has to type hit tab three times to > > edit PerMsgStatus.pm). > > I agree PerMsgStatus is an awful name. I'd really like to see it > changed. MessageStatus.pm would probably be good, having said that, a lot of > the stuff in there is more than status. I hope that's split off. agh, I'm being outvoted ;) But think of the backwards compatibility! PerMsgStatus is one of the main user-visible classes. Changing that name would be troublesome, IMO... > > Currently our codebase has some other big flaw: > > > > 1. (IMO) Mostly because of the flat namespace, the API is very confusing. > > Without very deep understanding of the infrastructure one can't really > > differentiate between the public and private stuff, which modules are just > > helpers and so on. (I'm hacking on SA since... um... some time in 2002 when > > Justin was still travelling around the world, and still often have to trace > > through the modules when I try to fix something). That makes it not only > > hard for other applications' developers to access the SA API but might also > > scare away possible new developers which we might need more of. > > Also, the API is very poorly documented. definitely the case. > > Some possible plug-ins which immeadiatly come to my mind are for one other > > Learner apart from Bayes. There was once a hack called Fitz [2] announced > > which was working with some kind of AI and looked interesting -- but I > > never got it running because it is a big patch and didn't apply to my > > modified codebase (and I didn't care *that* much that I fix the rejected > > parts). > > > > Another candidate for this are the storage backends -- it should be > > possible > > to store (all) your stuff into an SQL database or wherever you want. The > > SQL stuff currently scattered thorugh the whole codebase and some parts are > > AFAICS heavily outdated. > > Right. I'd like to see more opportunity to take full advantage of > Object Oriented programming. (i.e. inheritance etc.) People should be > able to derive a class from a base class to extend SpamAssassin to do > what they want. (I'm sure I'm misusing some of the jargon, but I hope > you understand) Hold on -- on this point, I'd be very careful. Nowadays, inheritance is *not* used that much, due to the ease of which it collapses into "spaghetti inheritance". Inheritance *is* still used in a Java interface style -- namely there's a base class which defines the interface to support, and then an implementation class, which implements that interface. This way, someone who wants to override some behaviours can provide their own implementation, without relying on the original impl class; they just have to rely on the "interface". We already use some of this -- Mail::SpamAssassin::Message is an interface, implemented by AuditMessage, NoMailAudit etc. although we're probably going to dump it now ;) However -- the upcoming Plugin API is a decent OO API ;) > > PerMsgStatus.pm Status.pm > > Shorter is better :) > > I think there's a lot of stuff in PerMsgStatus.pm that should be split > out -- like re-writing and stuff. +1. Also the get() and get_decoded*_body() APIs should not be in there. > > Hm. I think that was it. Comments, flames, patches? :) > > patches? keep dreaming ;-) > > One other thing I'd like to see done for 3.0 is that we should take a > look at the spamd protocol and see if there's anything we'd like to > change about it. We should then either write an RFC (or an Internet > Draft) about spamd and apply for a port number from IANA. We've always > been using 783, which is currently reserved, but it's not officially > assigned to spamc/spamd. The right thing to do would be to officially > register it, and for that we need a permanent reference for the spamd > protocol. Good point. BTW the spamd protocol is pretty good if I say so myself ;) I don't think much needs changing -- apart from possibly some edge cases and "where is the newline" style issues. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Exmh CVS iD8DBQFAD2JJQTcbUG5Y7woRAhYaAKC0B0cp/Bk59itg24wCsRRzmEscqACePgeS 5BTMud8RiSNnwWgJvmMcn1g= =R0u/ -----END PGP SIGNATURE-----
