[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] CD-Text API changes
From: |
leon |
Subject: |
Re: [Libcdio-devel] CD-Text API changes |
Date: |
Mon, 12 Mar 2012 08:48:03 +0100 |
User-agent: |
Roundcube Webmail/0.7.1 |
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