flac dev - Sep 2004 - Binary compatibility (was Re: Sound Font FLAC)

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

On Thu, Jun 14, 2001 at 07:27:50PM -0700, Josh Green wrote:
> Right. Seems like going one step further and keeping the structure private
> and just having access functions might be even better?
Yes, I agree.  See the pthreads API for a good example of how this can be done.
I saw something go by on this list about constructors and destructors for
libFLAC; that is probably a step in the right direction.

-- 
 - mdz

Matt Zimmerman wrote:
> 
> 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.
> 
Right. Seems like going one step further and keeping the structure
private and just having access functions might be even better?
	Josh Green