As my plan for world domiation though efficient string caching unfolds, the
next step is rewrite the guid -> url multimap for GetFilename.
The MetaData does not know the url. It knows the guid, which a keys to
one (or more, it is a multimap) of urls.
I see the Metdata is further wrapped into the PlaylistItem which
holds:
private:
MetaData m_metadata;
string m_url;
PlaylistItemState m_state;
};
And the MusicCatalog has the methods:
void WriteMetaDataToDatabase(const char *url, const MetaData metadata,
MetadataStorageType type = kTypeTrack);
MetaData *ReadMetaDataFromDatabase(const char *url);
string GetFilename(const string &strGUID);
..and various Add*(url) and Remove*(url) operations.
And it is the MusicCatalog that keeps track of guid->url multimap.
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.
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.
Given the metadata, you have the kludge of Getfilename. What is
the consequence of GetFilename shadowing some urls by only returning
the first hit?
Again, why is the sky blue? why is the grass green? why is url not
in 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
