Time to rethink the abstract Tag interface!

[Jeff Mitchell]

Anders--

While some of your points are good regarding return values and the like, I 
disagree wholeheartedly with your wholehearted disagreement:

> I wholeheartedly disagrees with this statement!
>
> I think that the tag interface should be considered the *main*
> interface to TagLib, especially if the number of formats will increase
> in the future. As the main interface it is imperative that it will
> meet the needs for most, if not all, applications. Today it does not!
>
> I suggest that the following changes should be done to the abstract
> interface:
>
>  * Instead of providing the intersection of the features of the
>    supported formats, the interfaces it should provide the *union*!
>    For example, the abstract interface should support attributes like
>    "number of discs in set" and multi-values tags. A good thing is if
>    an application could ask the interface what features are provided.
>    (Also, the methods that update a file could return a status, so it
>    could indicate that the application is setting an attribute the
>    format doesn't support.)

This doesn't belong cluttering up the Tag interface.  In fact, as new formats 
become supported, this would require constantly changing the public API of 
the base Tag class, which is a bad thing.

Now, if what you want is a way to get information about what features 
different implementing subclasses support, a better way to go about it would 
be similar to TagLib::File::audioProperties.  That method is a pure virtual 
method that returns a block of well-known data with basic information about 
the file (length, bitrate, etc.).  Similar to this, define a pure virtual 
method that returns a data structure containing information about what 
features a particular tag type supports.  This could be done in various ways 
to trade off ease of querying vs. memory size vs. query speed vs. methodology 
of adding new features (for instance, an easy one, but one that would eat up 
a bit of time ane memory, would be using a map; you could simply query 
whether keys exist matching your TString feature values).

--Jeff