mitchell at kde.org
Mon Jan 25 09:31:14 PST 2010
On Mon, 25 Jan 2010 12:15:02 -0400, Karl Vollmer <karl.vollmer at gmail.com>
> - I don't like the FMPS_???? syntax, but I see no way around it,
> nature of the beast. so o.o)b to that
Yeah. As has been discussed several times before on the various threads of
this discussion, the necessity of riding on top of various tag formats with
different capabilities, fields, and syntax means that to ensure that you
know what data you're looking at and how to interpret it you must have
context, which in this case is via FMPS_????. It's similar to a schema
declaration for XML -- without something to validate the XML against and
give it context, you can read it but it may be totally meaningless.
> - We should restrict the allowed UTF-8 character set to non-control
> characters. I'm pretty sure nobody wants a NULL or LF/CR in an
> identifier. I'm not sure exactly what exceptions should be allowed in
> the value, such a allowing NULL delimiters or something?
After thinking about this a bit and looking at the Unicode specs (and
bringing it up to the VLC guys), I think that this is something best left
up to $your_local_string_library. Defining ranges of values not allowed
means everyone has to then check whether such values exists, the ranges
must be exhaustive, and it generally makes it harder all around (it would
be by far the most complex part of the spec) -- and most string libraries
probably take care of this for you in the first place, at least when you're
going to display the data. So I'm leaning towards letting libraries do
their job and keeping things much less complex.
> Beyond that I'm happy with the spec, and would be willing to implement
> it in Ampache. As far as adoption I should be able to add read support
> rather easily, but write could be more complex. It might be worth it
> to build an "exporter" for Ampache / Amarok that would write out this
> new tag format to your files in batch so that we can start to get
> files out there with these tags.
Well, remember that they're just identifiers -- not a new tag format. Once
v1.0 is finalized, I'll be adding write support into Amarok, although I may
have it off by default -- users generally don't want their files touched
without explicitly enabling/requesting it.
I have to think a bit about lyrics -- it would be nice to have lyrics in
the spec, but in many cases the lyrics are going to be copyrighted. (Not
that that stops sites like MetroLyrics, and arguably it's beneficial to the
artist, but I digress.) I guess that's up to the user to use it properly...
More information about the xdg