[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 |
Hi,
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 :)
Thomas
- [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB), Rocky Bernstein, 2018/07/08
- Re: [Libcdio-devel] Split libiso9660 into its own project? (Was Re: [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB), Pete Batard, 2018/07/08
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB,
Thomas Schmitt <=
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Rocky Bernstein, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/09