-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Parker writes: > 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* oops -- good point Malte! yes, that'd break ABI compatibility, which is a big deal with C (like coredumps). > 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. +1 > > 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? well, 3 years is plenty of time by now ;) but if it's painless to leave it in, might as well leave it in in my opinion. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCPoSQMJF5cimLx9ARArvyAKC0Ml67fJ0qfryDSP9fm1flODpqPACggUq+ hjTzBXRmi7SqS5zwFxtvnKM= =h9hU -----END PGP SIGNATURE-----
