[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Mon, 09 Jul 2018 09:33:35 +0200


hm, the discussion becomes even longer than the huge changset.

My fundamental consideration is that we use interfaces to coordinate
our work. Ideally those interfaces should be designed perfectly, but in
practice forecasts are tricky, especially if they concern the future.

So it is helpful to have a meta interface which governs how changes of
the programming interfaces shall happen and who is in charge to adapt
existing code to those changes.
We are now discussing this meta interface.

My idea of it is:

* Never break the API (source code compatibility) of a library.
  If it's broken, then the library can as well get a new name.

  This is quite a necessity for all distro maintainers, who have to
  build software which they do not know in depth.
  It is also a courtesy towards the developers of applications who
  would else be forced to change their code without own motivation.

* Try hard to keep the ABI usable for old programs which have been
  compiled to use an older version of the dynamic library.

  This is a courtesy towards the users of applications. They can carry
  them to more modern versions of their operating system without the
  need for recompilation (which might be not trivial).

* Design the API/ABI for being expandable without conflicting with the
  first two rules.

  To our luck there is a broad trail of other software which already
  relies on the opportunity to attach new members to structs without
  disturbing the older members.

This ideal is quite common in the plumbing layers of GNU/Linux.
It is much less visible in its desktop world.

I blame the short breath of GNU/Linux GUI developers on that porcellain
fragility. All three big burn GUIs are effectively orphaned currently,
while two of the three burn backends are well alive.


It seems that i forgot to consider language bindings in my proposal.
I will explore this aspect in the next days. (Expect questions.)

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]