move Meta::Album::image to Meta::Track::image

Maximilian Kossick mkossick at gmx.de
Wed Jun 27 09:11:31 CEST 2007


On Wednesday 27 June 2007, Ian Monroe wrote:
> On 6/26/07, Maximilian Kossick <mkossick at gmx.de> wrote:
> > > > We know that our album handling is not optimal, so should we not try
> > > > to improve/fix it instead?
> > >
> > > Well that is the main reason why I sent the patch to the list. I can't
> > > really think of another way to do it.
> >
> > As mentioned above, the way we store and load the album covers is an
> > implementation detail of the particular collection. And the (current)
> > implementation of one collection should not influence the api all
> > collections have in common (if we can avoid it) imo.
> >
> > Max
>
> The fact that we currently implement it as a Artist/Album is I think
> not merely a implementation detail, but a design decision. Images were
> associated with Artist/Album not simply as the way to kept track of
> covers out of a necessity from the "string-based" way we were doing
> things, but because there is no clean solution to uniquely identifying
> Albums and keeping 20 different "Greatest Hits" albums apart.

Hm, now that you mention it, I think Sqlcollection will only create 
one "Greatest Hits" album object at the moment. That's broken and needs to be 
fixed.

Magnatune provides a nice xml file, which includes one cover per album, and 
Nikolaj stores it that way in the database. That makes the Artist/Album 
implementation of Amarok 1.x an implementation detail. We can still use it in 
SqlCollection.

> Its impossible to use this design with Meta::Album's having the image,
> unless you create a new Meta::Album for each Album/Artist combination.
>  Or pass the artist name to Meta::Album::image method, since
> (disregarding the rarely used "Album Artist") the Album has no
>
> ::artist().

As mentioned above, not all Collections have this problem. If SqlCollection 
needs the Artist in Meta::Album::image, we should add the necessary code to 
SqlAlbum/SqlArtist/SqlTrack.

> To keep the Meta::Album::image in its current location does require a
> new implementation and design for covers. Which is worth thinking
> about. Perhaps some keen way to keep different albums of the same name
> apart and then use a new database design to keep track of it all. We
> already have similar sorts of smarts for finding compilation albums
> (guessing based on what directory the files are in and such). But I'm
> not sure its possible to do it reliably.

One more topic to discuss at Akademy... :)

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070627/f214e8ba/attachment-0001.pgp 


More information about the Amarok-devel mailing list