On 2009/01/31 03:52, Stefan Monnier <monn...@iro.umontreal.ca> wrote: > > yesterday, I have implemented a feature that has been awaited for a > > very long time: the sticker database. It is a database where you can > > attach additional information (name/value pairs) to objects, e.g. to > > song files. > > This last "e.g." seems to imply that songs are but one of the possible > places where you can attach info. But doc/sticker.xml doesn't mention > any other place.
Songs are the first and currently only objects you can attach stickers to. If that idea works out well, we will continue to develop it. Since my first implementation, I have worked on other new MPD features which I wanted in 0.15, and havn't made any progress on the stickers. We could extend that to attaching stickers to artists, albums, directories, .... i.e. every object which is managed by MPD. There are some problems to be solved for some types, but it is possible. > The problem with "per-song name/value pairs" is that it doesn't provide > any more functionality than tags stored directly inside the song files. > Or rather, the only extra functionality is that you can change them via > the MPD protocol. > > So maybe a better feature would be to make it possible to change the > meta-info of files directly via the MPD protocol. MPD will never write to song files, if you mean that - MPD always assumes it has only read access to these files. You might write a server-side program which copies stickers to the song file (vorbis comments?), but that is an additional program. This way, MPD clients could indirectly edit song metadata. > Then again, maybe not. E.g. the functionality currently offered is > not sufficient to provide per-user song ratings and making it > possible to write the song's metadata wouldn't solve that either. It is sufficient, if you say "rating" is the global rating, and "rating.USERNAME" is one user's rating. The limitation is that MPD provides no separation of "rating spaces", i.e. any user can see and edit any other user's ratings. I think having a per-user sticker space would be over-engineering. > W.r.t the "style" sticker, maybe a better solution would be to use > "genre" for that, and then provide a way to classify genres. The > classification hierarchy (probably a DAG actually) could be stored > in some extension of the sticker database (where the info is clearly > not per-song any more). > > Along similar lines, the album_rating shouldn't be stored "per-song". > Instead, each song should contain some "album id", and then the album's > data can be associated with that album id. This would allow to > distinguish between the song's date and the album's date (for > compilation albums), would provide a good place to store album covers as > well, etc... > I'm not sure what "album ids" should look like, but in my music > collection, each album has its own directory, so if it's a common usage > pattern, that could be a good solution. See above, the "album id" is indeed the problem. MPD does not have real objects for "albums", they are purely virtual, and the album list is generated each time a client requests it. To provide stickers for these virtual objects, we have to pin them down server-side somehow. Will be solved. Max ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
