On Thursday 22 January 2004 06:40 CET Justin Mason wrote:
> 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 ;)
There're still other who haven't spoken yet :)
> But think of the backwards compatibility! PerMsgStatus is one of
> the main user-visible classes. Changing that name would be troublesome,
> IMO...
As I said before, we'll probably change the interface so changing the name
would be the smaller problem.
We could (note I said "could", not "will" :) even offer a drop-in
replacement PerMsgStatus.pm which is just a wrapper around the new module
but behaves like the old one...
> >[...]
> > Also, the API is very poorly documented.
>
> definitely the case.
Hrm. That was "3. [Got to remember this one.]".
> > 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.
IIRC is "real" OOP with inheritance relatively slow in Perl but I can be
proven wrong. We must of course not loose the focus on the speed aspect
while we're refactoring. But in some places inheritance might indeed work.
> 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 shouldn't inherit deeper than one level, I think.
> 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 ;)
Heh.
> 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.
+1
> > > 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.
I think I once in a bored minute proposed another protocol which was more
SMTP-like. Not that I don't like the HTTP-style protocols, but it isn't
possible to play ping-pong with those. I think. Please prove me wrong.
The above would be useful for persistent connections or stuff which we
currently had to implement via REPORT_IFSPAM. Something like this:
spamc: CHECK
Content-Type: message/rfc822
Content-Length: 123
<data>
spamd: OK
Result: Spam
Score: 42.0/5.0
spamc: REPORT
spamd: OK
Content-Type: message/rfc822
Content-Length: 234
<data>
spamc: NOOP
spamd: OK
spamc: CHECK
Content-Type: message/rfc822
Content-Length: 123
<data>
spamd: OK
Result: Ham
Score: 0.0/5.0
spamc: QUIT
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
