[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: Pete Batard
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Sun, 8 Jul 2018 15:22:48 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

On 2018.07.08 14:52, Rocky Bernstein wrote:
I hope I am reiterating something that is consistent with consensus
opinion: the next release we go with the compatible ABI and Thomas'

Well, I guess I wasn't clear enough then, as I disagree with this approach.

My vote is to *NOT* apply any multiextent changes until we are in the process of preparing a new major release, and then go for the much simpler ABI-breaking proposal (i.e. ditch Thomas' latest proposal and use mine instead, albeit possibly with Thomas' dynamic allocation changes, which I don't feel are warranted, as I tried to explain earlier, but that I don't see much harm in having if we really believe that people are going to use super large multiextent ISO-9660 on systems where they can't use anything but shared libcdio libraries).

In my view, Thomas' proposal is way too disruptive for both libcdio and its users, whereas, if we simply decide to wait until we feel that we have a good window for an ABI change, we can get something a lot less painful for everybody. I have a very strong feeling that, if we decide to go with integrating Thomas' latest proposal, it will come to bite both us and our users, and the cost/benefit ratio will not be in anyone's favour.

So my current vote is against integrating these changes, and instead go with the much simpler and therefore a lot less disruptive earlier proposal, that requires an ABI upgrade, even if that means _waiting_ months or years until we feel that the time is ripe to apply these changes.

But again, that is just my vote. If there is a majority leaning the other way, I am certainly not going to oppose the integration of Thomas' latest proposal.



reply via email to

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