[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
Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Sun, 8 Jul 2018 15:22:48 +0100
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
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'