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

[leon]

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.

> 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