On Sat, Apr 17, 2010 at 22:02:14 (CEST), Jonas Smedegaard wrote:

> I think others have tried pointing it out to me already, and it begins
> to get through my thick skull: Even if both ABI and API is compatible
> across implementations, it is _application_ ABI and API - the daemon use
> a _different API/ABI which is not set in stone so switching daemon
> forces a switch of library too.  Was that correctly summarized?

There are multiple interfaces here at runtime:

 1. application <-> library
 2. library <-> daemon

the (library) ABI is only guaranteed for level 1. different
implementations of libjack/jackd may implemented a different protocol at
level 2.

the *API* is a compile time concept. It is a fixed set of API calls and
globals that is written in stone in the jack documentation. Any
application using some internal is buggy and needs to be fixed.


Please note that commongly, ABI refers to the machine binary interface,
which only matters of you are talking about porting. For this reason,
I've already seen people that claim the ABI as discussed in this context
to be actually part of the API, with contributes to the confusion even

I'd therefore suggest to talk about the library ABI, which means the
protocol between an application, the dynamic shared library loader and a
shared library at pure run-time (mostly load-time).

Reinhard Tartler, KeyID 945348A4

pkg-multimedia-maintainers mailing list

Reply via email to