[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    BC in libspamc (was: svn commit: r158029 [...])
From:       "Malte S. Stretz" <msquadrat.nospamplease () gmx ! net>
Date:       2005-03-21 0:18:48
Message-ID: 200503210118.52442 () malte ! stretz ! eu ! org
[Download RAW message or body]

On Friday 18 March 2005 08:46 CET parker@apache.org 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).

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.)

Maybe we need to decide on some kind of possibly stable public C API (which 
could supersede libspamc as eg. libspamassassin) but somehow we should 
watch out for BIC changes.

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 ;~)

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>
[prev in list] [next in list] [prev in thread] [next in thread]