Extending TagLib::Tag's interface.

[Lukáš Lalinský]

Dňa St, 2008-04-23 o 18:04 -0700, Peter van Hardenberg napísal:
> 2) Tag::*
> 
> Attached is a patch against tag.h which adds a whole heap of fields to
> the base interface. I have been implementing all these fields using
> the most canonical information available, the ID3v2 spec, the Xiph.org
> wiki, the Creative Commons wiki, and such. When I have the rest of the
> tag formats implemented, I'll attach a new patch and then we can work
> out the details of field names on a per-field/per-tag basis.
> 
> Which bits of metadata deserve promotion to Tag::*? Which ones are just
> giving me carpal tunnel for no reason? 

I don't think this is a good way to proceed. You will never have 100%
solution to this problem, because the various tagging formats TagLib
uses are not compatible with each other. So any solution you will try to
implement, will not work universally. I think it's better to leave this
kind of decisions to TagLib users. For example there is nothing like
'album artist' in ID3, and there is no consistant way of writing it to
Vorbis Comments or APEv2 tags, so implementing albumArtist() doesn't
make sense to me if it won't work universally.

> 3) Tag::supports*
> 
> Currently, I allow setting an unsupported field on a tag as a no-op,
> and getting to return null/0/false. Right now I think adding
> "supportsWhateverField()" with a default implementation of "return
> false;" would be a reasonable way to let people figure out what their
> tag formats will do for them. I prefer no-opping to explicit failure
> for unsupported fields since writing out metadata is usually a
> non-interactive process where as much information as the file can
> capture is written. If that makes people go all squinty and press
> their lips together with disapproval I might be convinced otherwise.

See below.

> 5) Tag::set(anyProperty)
> 
> In addition to the core metadata properties I would like to be able to
> set my own completely arbitrary properties in a generic way across all
> supported Tag implementations. I would also like to be able to
> enumerate these properties, and, maybe even as many of the properties
> as can be reasonably interpreted. This is probably worthy of a thread
> all its own.

Here is a few notes:
 - you can't get a universal mapping of 'arbitrary properties' across
tagging formats (http://wiki.musicbrainz.org/PicardTagMapping is my best
attempt)
 - all modern tagging formats support multiple values per field, there
is no reason to ignore this if you are going to implement this free-form
way of tagging
 - I think this should be implemented as a separate library on top of
TagLib, and I'd love to see the generic Tag methods (artist/title/etc.)
to be removed in the future

Lukas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?ISO-8859-1?Q?digit=E1lne?=
	=?ISO-8859-1?Q?_podp=EDsan=E1?= =?UTF-8?Q?_=C4=8Das=C5=A5?=
	=?ISO-8859-1?Q?_spr=E1vy?=
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20080424/0fc8c407/attachment.pgp