Re: [Libcdio-devel] CD-Text API changes

[Rocky Bernstein]

On Mon, Mar 12, 2012 at 3:48 AM, leon <address@hidden> wrote:

> On 2012-03-12 01:20, Nicolas Boullis wrote:
>
>> I am a bit curious: why does cdtext_select_language take a "const char *"
>> parameter for the language, while cdtext_get_language and
>> cdtext_languages_available return cdtext_lang_t value(s)? Wouldn't it be
>> more consistent if cdtext_select_language too, a cdtext_lang_t
>> parameter?
>>
>
> First I thought it to be easier this way. But the more I think about it,
> keeping localization in mind, the less I like it. Any other opinions?
>
>
>  Now, as for the API and ABI changes...
>> I have no problem with the API change, as long as this part of the API
>> currently is seldom used (if I understand things correctly).
>> I am more concerned about ABI changes, because the whole library must
>> "say" whether it is compatible with previous versions. If it is said to
>> be incompatible, then evrything needs to be rebuilt. On the other hand,
>> if it is said to be compatible while it is not 100%, then users who use
>> the new one with programs built against the old one may experience
>> crashes.
>> So, for me, the question is: is the new ABI compatible with the old one,
>> and if it is not, should it be made compatible?
>>
>
> It is not.
>
>
>  You only specify the API, bu I guess the ABI roughly is a 1-1 mapping of
>> the API. Then it means the new ABI is incompatible with the old one.
>> Should it be made compatible with the old one?
>>
>> Thanks to symbol versionning, it should be possible not to break the
>> ABI, by shipping old symbols alongside with new ones. For example, we
>> may have both cdio_get_cdtext@@CDIO_13 and cdio_get_cdtext@@CDIO_13_1
>> symbols, while only the latter is exposed by the API. As far as I know,
>> this is roughly how things work with glibc. (It would be unacceptable to
>> have the ABI of glibc change often and require a rebuild of roughly
>> everything.)
>>
>> As I understand it, adding the old symbols would require to resurrect
>> the old cdtext_t type (with a new name), the functions whose prototype
>> has changed (of course) and all those that used the old cdtext_t type
>> (since their binary interface changed as well).
>>
>
> It most likely would require this, yes. Practically it would be the same
> as providing two different versions of the functions, as we discussed some
> days ago. We abandoned that idea because of the massive complications it
> would have caused.
>
>
>  Moreover, this would require some more work on symbol versionning, as we
>> currently define all symbols with the same version, which we wouln't be
>> able to do any more.
>>
>> Now, is worth the effort? If I were a purist, I'd certainly say it is.
>> But being somewhat pragmatic, and despite I hate ABI changes, I think it
>> is too much hassle.
>>
>
> I am not a package maintainer and I do not know how they think. How big of
> a problem would it be to have it changed?
> But there are only two projects I know about that use libcdios CD-Text and
> I will try to help them make the necessary changes.


Depending on how you count, possibly more than two. Currently
example/C++/OO/cdtext.cpp still needs fixing. The various library bindings
for libcdio (rbcdio, pycdio and Device::Cdio) need fixing. Is this
considered a separate project? (Currently the Device::Cdio repository is in
github.com rather than Savannah's git. I think I did that when I got
annoyed with Savannah's git.) And then there is the gstreamer cdda plugin.
I wrote a vlc plugin that I don't think is still in the repository, but
that could be resurrected. And I there may have also been an mplayer
plugin.  These are all the things I know about.

>
>
>  Now, a side note: shouldn't CDText functions be kept in a separate
>> library, distributed with libcdio, just like libiso9660, libudf and
>> libcdio-cdda? This would allow to break the ABI of this new library
>> without breaking libcdio's ABI. Any opinion on this?
>>
>
> Hm how would this help with the current problem? If the new libcdio
> version will not have the cd text part, it would essentially mean another
> ABI change...
>
> Regards
> Leon
>
>