On Mon, Mar 21, 2005 at 01:18:48AM +0100, Malte S. Stretz wrote: > On Friday 18 March 2005 08:46 CET [EMAIL PROTECTED] wrote: > > Author: parker > > Date: Thu Mar 17 23:46:45 2005 > > New Revision: 158029 > > > > URL: http://svn.apache.org/viewcvs?view=rev&rev=158029 > > Log: > > Bug 1201: Add learning support to spamd/spamc > > > >[...] > > +++ spamassassin/trunk/spamc/libspamc.c Thu Mar 17 23:46:45 2005 > >[...] > > -int message_filter(struct transport *tp, const char *username, > > +int message_filter(struct transport *tp, const char *username, int > > learntype, int flags, struct message *m) > >[...] > > -int message_process(struct transport *trans, char *username, int > > max_size, > > +int message_process(struct transport *trans, char *username, > > int learntype, int max_size, int in_fd, int out_fd, const int flags) > >[...] > > /* Aug 14, 2002 bj: Obsolete! */ > > -int process_message(struct transport *tp, char *username, int max_size, > > - int in_fd, int out_fd, const int my_check_only, > > - const int my_safe_fallback) > > +int process_message(struct transport *tp, char *username, int learntype, > > + int max_size, int in_fd, int out_fd, > > + const int my_check_only, const int my_safe_fallback) > > message_foo are our public routines in libspamc, aren't they? And changing > the parameter list is not Binary Compatible (especially in C), isn't it? > The same is true for the structs I guess (am no C expert).
*grumble* I'm also no C expert and really wasn't focused much on the spamc/libspamc code. I struggled to change how the options are given for spamc. Possibly the best course of action would be to add a message_learn call to libspamc and call that from spamc instead of passing through the learntype in message_filter/process. In extension, should we ever add the ability to report we can add message_report. > I think we did not define yet how "public" the libspamc interface is, but > IMO should we try to keep BC in libspamc. If we tend to break it, we > should introduce some kind of versioning for libspamc. > > Keeping BC is a real PITA, but breaking all third party apps which link > against libspamc just because the user updated his version of SpamAssassin > is really rude. (Think OpenSSL if you want a bad example.) > Agreed, it was unintentional, and on further reflection, probably done in a better way. I'll see if I can get something workable. > Oh, and I guess we should just remove old stuff like process_message as it > was marked obsolete since 2002 and changing the fingerprint will break > backwards compatibility anyway ;~) How do people feel about removing it? Michael
pgpZpFuTwnkHe.pgp
Description: PGP signature
