Binary compatibility (was Re: [Flac-dev] Sound Font FLAC)

[Matt Zimmerman]

On Thu, Jun 14, 2001 at 05:51:43PM -0700, Josh Green wrote:

> I managed to create an encoder for the audio chunk of a sound font (have yet
> to do any meta data block for gzip compressed non-audio data, there will
> probably be 2 METADATA blocks to simplify things, one for before and one for
> after the audio chunk). All seems to function alright. I do have a few
> comments on the design of the libFLAC API. The FLAC__stream_encoder_init()
> function call has quite a lot of parameters.  Do you forsee a reason to add
> or modify any of these in the future? I would think that creating an init
> structure to pass to this function would make sense. Or even better would be
> to have some functions for setting parameters in the FLAC encoder instance (I
> notice you already have functions for getting parameters). The FLAC encoder
> instance could then have default values, and there would be certain
> parameters that would be required to set. Not setting an optional parameter
> would just cause the default to be used. What do you think? It seems like the
> current implimentation will be a nightmare to try to keep a backwards
> compatible libFLAC API.

I think it's a good idea to create a structure to maintain source level
compatibility.  This reminded me about the issue of binary compatibility,
though.  Since libFLAC can be built as a shared library, this is an issue which
should be addressed starting with 1.0.  The soname version should be
incremented (it is currently at 0), and future ABI changes must be accompanied
by a soname version number increase.  This is required to allow programs
dynamically linked against libFLAC to continue to work.

-- 
 - mdz