On Mon, Feb 15, 2010 at 02:03:35PM +0100, Daniel Stenberg wrote:
> On Mon, 15 Feb 2010, Domenico Andreoli wrote:
>
> >I don't agree with you, ABI and API are well defined concepts.
>
> I disagree. Please point me to that single unambiguous definition.

Wikipedia explains the concepts in a way I agree with:

http://en.wikipedia.org/wiki/Application_binary_interface
http://en.wikipedia.org/wiki/Api

I associate relationship between ABI and API to the one between syntax
and semantics. First one is a brutal formal matter which could be easily
checkd by a machine, it's a strict contract that must be always respected
otherwise things break badly. Second one is more thin, it is generally
not easy to say what is allowed and what not, it simply depends on how
the parts interact.

> To get back to the details again (since I believe a meta discussion
> around this topic isn't taking us further one bit). In what way
> would you say my reasoning is flawed in regards to when an existing
> app using the options added in 7.20.0 and they downgrade to libcurl
> 7.19.7.

Do you imagine libc bumping API version every time a new option is added
to setsockopt()? Every application should be rebuilt to work with a
library that supports a new option the app does not even use. Moreover
the rebuild would not be required at all because ABI did not change
and the app would flawlessly run on the new lib.

On the other side an application using the new option, once run on
the older lib, would simply receive a EINVAL error. A good application
always checks return values and whether it can recover from the error or
not depends only on the option requested and the application, something
the library designer cannot suppose to know in advance.

> If we can just link (even run-time) the app with the lib, do you
> consider the ABI fulfilled? If not, what other requirements do we
> have to fulfill to claim that we're maintaining (backwards)
> compatibility?

In an ideal world, once linking is finished ABI could be guaranteed.
Unfortunately objects do not contain all the info required to let the
linker check also ABI matters, so in the real world a successfull linking
does not imply ABI compatibility. Anyway I think mostly depends on the
language calling convention.

Please define the side of "backwards compatibility" you are interested
in. I think libcurl already provides great backwards compatibility with
existing applications. Backwards compatibility of an application with
regard to existing libcurl versions is a matter of the application
writer, not of libcurl. libcurl cannot do anything besides signaling
with a Big Red Flag (tm) that something is wrong.

> If an application that runs fine with 7.20.0 suddently just stops
> working in a significant (and documented) way with 7.19.7, can we
> really claim that those two libs are compatible?

ln command runs fine on ext3 but suddenly just stops working in a
significant (and documented) way on NTFS, can we really claim that those
two fs are compatible?

Compatible for what? Tons of jobs can be done on both filesystems but
a simple ln does not work. The answer simply depends on what you are
using them for and how you react in front of an error you may get.

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-02-15