On Mon, Mar 12, 2012 at 3:48 AM, leon <[email protected]> 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 > >
