On 28-Sep-2000 Chris Kuklewicz wrote:
> Here is where a design document would help. What is the GUID, and
> what is its purpose in life? Answer: it is what the music brainz library
> generates into char guid[17].
>
> It's not a unique id since two different songs may have the same GUID
> but different urls. Thus the multimap. But GetFilename simply
> presents the first match returned. The only routines that notice
> multiple values with same GUID key are the Remove operations, which
> erase all the matches.
It is a unique id for the song. 'Course, people may have the same song
multiple times in their collection.
> So why rely on the guid->url mapping? Since PlayListItem simply
> combines metadata with url, why not put the url into the metadata?
> The url is the key into the database, and the url to metadata mapping
> is given by ReadMetaDataFromDatabase. With playlistitems, the one to
> one mapping of url and metdata is clear. But the meta->url mapping
> is clouded.
Database. url is the key, metadata is the data.
> Given the metadata, you have the kludge of Getfilename. What is
> the consequence of GetFilename shadowing some urls by only returning
> the first hit?
It's not really a kludge. It'll return what's desired -- a song that matches
that GUID.
> Again, why is the sky blue? why is the grass green? why is url not
> in MetaData?
It's just an issue of separation.. a PlaylistItem has a URL and associated
MetaData.
> I want to grok the design before I replace the map of strings with a
> map on char*. I do not want to redesign where the url is stored, but
> I do want to understand how it got to be the way it is.
>
> --
> Chris
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
