Any appetite for a 'normalisation' layer over non-std tags?

[Adam Szmigin]

Hi Scott,

On 13/04/17 16:25, Scott Wheeler wrote:
>
>> On Apr 11, 2017, at 07:58, Adam Szmigin <adam.szmigin at xsco.net> wrote:
>>
>> Ok, so the Tag class is the normalisation layer, but only for the 7 'standard' fields.  I suppose my question has now evolved slightly: is there appetite for adding additional fields (such as composer, album artist, etc.) into the Tag class, either now or in taglib2?
>
> Probably not, for the reason that has already come up in this thread:
>
> We can't add or remove virtual methods from classes within a release series, e.g. everything in TagLib 1.x has to have the same set of virtual methods, and everything in TagLib 2.x will have the same limitations.  That's why the property interface was added since it allows for a dynamic set of properties over the many years that a set of virtual functions would need to stay stable.

My apologies, I should have been more specific with my question: I do 
understand that adding new _methods_ like Tag::composer() would result 
in an ABI change, and hence is resisted.  No issues with your position 
on that.

What about adding new _fields_ such as COMPOSER, ALBUMARTIST, etc. to 
the PropertyMap returned by Tag::properties()?

Currently, only File::properties() (and the subclass-specific 
PropertyMaps) contain these extra fields, and Tag::properties() does 
not.  Adding extra fields to Tag::properties() would not break the ABI, 
if I understand correctly.

If there is appetite for this, I'm happy to do the work and submit a patch.

Many thanks,

-- 
Adam Szmigin