Started 2.0 branch

[Ralf Engels]

> > all.
> 
> Why not just create a branch in KDE's subversion repo?
> 

currently taglib is in the trunk or kdesupport which marks it as the
currently in-development version.
I don't have any clue how I could place something next to it, so that
everybody can understand what's going ont.

> 
> My question would be: Why not use git & github instead?
> 

I still have the hope that Scott would merge my development back if it's
advanced enough. 
This back and forth probably works best when I don't change the revision
control system at the same time.

> I'm also curious if there's some plan behind a 2.0 release. Will it be a
> complete rewrite? What changes should be done?
> Granted, I've not been on this list for a very long time, but I haven't
> seen much more discussion about this other than "we should create taglib
> 2.0".
> 

There were some discussions about this some time ago. Actually the plan
was the same.

> One thing that bothers me about taglib is that I need to access less
> common metadata than what the basic fileref offers, and maybe I do it
> wrong, but it seems like you have to do quite some juggling for that. I
> don't want to mess around with ID3v1/ID3v2/APE/VorbisComment/etc, I
> pretty much want "open(file);", "[gs]etValue(<key>);" and "save();".
> 

Right. That's also what I want to do.
Currently this only works for a tiny subset of all usefull informations.
Everybody else (WMP, itunes) support four time as much.

> Also, is it just me or did you forget to tell us where we can find your
> repo?
> 

Will be set up next week. Hopefully with my first batch of changes.


> The thing is that it's not that simple. Various tagging formats
> support various features, you can't use a generic API unless you
> ignore some of the features. Ignoring them is fine for some
> applications, but it might not be for others. That's why I still think
> the generic API should be one level above the format-specific API (you
> could easily write one using the current TagLib API).
> 

Not a problem with the current setup.
Taglib::Tag supports the high level interface (currently in the format
setAuthor) and subclasses of Tag do the dirty stuff.

It's just that everybody needs to add to taglib to make it usefull for
their musicplayer.
I plan to change this so that Amarok can use the vanilla taglib.

And it needs to support popularimeter and seamless playback tags for
Christ sake. 

BR,
Ralf