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. > 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. > 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) > So, what were my ideas, my "draft" for 3.0 (and after)? > > SA 3.0 should be a first step into the direction of SA-as-a-framework. We'd > make some backwards-incompatible changes, break "binary compatibility" (if > you can say so when you talk about Perl :). Those would include: > * A cleaner API/module structure (as started by Theo). > * A new config parser (including a more flexible file format/backend) which > I started to write. > * Some cleanup of the frontends (like getting rid of some command line > parameters and moving them to the config files). > * Some possible other code move (which I started with spamc). > * Rename the Autowhitelist :) > * Some stuff from Matt's sa-3.0 stuff? I didn't look at it again because I > didn't want to get "tainted" by non-ASL code. > * ... other ideas? * Make sure the API is well documented > But 3.x won't be the final "framework" I was talking about. I don't think we > can plan everything in advance (I know I can't). I also don't want to start > from scratch. That never works out. We need to make a first step into the > right direction and then go on with refactoring till we're where we want to > be. And we need input from the outside, the possible plug-in writers. I see > 3.x as a "moving target" -- which doesn't mean it's unstable all the time, > just that the "plug-in" API (and other stuff) may change. When we finally > have something we like, we call it 4.0 and all world is happy :) I'd like to think that we can accomplish most stuff for 3.0. > My rough timeplan would be to get 3.0 out around the end of March (because I > write exams in the first two weeks of the Fabruary and have two free months > afterwards where I have time to code :). I expect 4.0 not before Summer > 2005 (I guess the spam problem is not solved till then). Also possible that > there won't ever be a 4.0, we'll see. But it's nice to have a rough target > to aim at. Wow... 4.0 seems so far away... but it's probably accurate (or underestimated) :-) > As a first concrete step I propose (something like) this move of modules > (annotations on the line below the module, you should have tabs of eight > spaces): > 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. > 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. http://www.iana.org/cgi-bin/sys-port-number.pl -- Duncan Findlay
signature.asc
Description: Digital signature
