Discussion here is easier than on the etherpad. Please watch the page to know when it is updated.
We keep one collection that can morphed into different views (possibly a tree view, list, grid, whatever) 3 modules: database manager, collection manager, ui
Left panel: click on artists Middle Pannel > ??? collection view sorts by artists(highest rated or alphabetically)
Left panel: click on albums Middle Pannel > ?? show album covers grid view, double clicking an album cover replaces Now Playing with all the tracks from that album
Left Panel click on Genre Middle Panel > collection view sorts by Genre
Left Panel click on Year Middle Panel > collection view sorts by Year ....
After some reflection and I think we should use a no-sql database, not to have to deal with other keys. See http://quodlibet.readthedocs.io/en/latest/development/faq.html#what-about-my-favourite-nosql-db-then.
'**' do we really need so much metadata, most of it is not directly editable by end users => yes but they might want to see it, and it's faster to read the database than compute something on the file each time we want to show it. foreign key relationships need to be defined properly before we implement in code
=> True for the foreing key relationship
All these tag should be tracked: http://taglib.github.io/api/classTagLib_1_1PropertyMap.html
QuodLibet does this and IIMO it's a great thing that most music players lack....
Do we do 3 tables Artist/Album artist/Composer or do we add a int in it to tell which type it is? For instance track artist = 1, album artist = 2, composer = 4 so that 3 means the two first (and so on)