Re: metadatabase

On Wed, 2003-10-15 at 10:18, David Hough wrote:

[snipped]

> Are you suggesting that the playlist manager should be an all in one 
> interface to both the library and editing playlists? What I mean by that 
> is are you suggesting that you would have a single PlaylistManager object 
> created which had an api that allowed any UI that wanted to query the 
> library about artists, albums, tracks, as well as read metadata about any 
> particular track. It would also maintain a copy of the current playlist to 
> control the player. Something along the lines of:
> 
> vector<std::string> playlist;
> context->playlistmanager->read_playlist("somelist.m3u", &playlist);
> context->playlistmanager->set_current_playlist(playlist);
> 
> could be done by the UI, and then the player could do something like
> 
> std::string url;
> context->playlistmanager->get_current_track(&url);
> context->playlistmanager->goto_next_track();
> 
> And this single object would also provide a way of editing playlists, like
> typedef Playlist;
> Playlist new_list;
> playlistmanager->add_track(new_list, "file://somefile.ogg");


I think this direction is fine, in fact I have an initial version 
with a vector like "playsheet" that is just a wrapper over
a vector<string> with some added functionality.. 

class Playsheet {
public:
    typedef std::vector<std::string> playlist_type;
    .... other typedefs
public:  // vector interface
    iterator begin() { return m_urls.begin();}
    iterator end()   { return m_urls.end();}
    ... other vector intrfaces

public: //Extended interface
    Playsheet();

    uint32_t find(const string&url);
    void shuffle();

   ...
}                                                                                              

One thing that I don't see is a nice interface betweeen
the UI's playlist and the player's playlist.   I really would
rather see them as completely seperate objects (possibly
in different address spaces) communicating with 
a minimum of information to maintain a consistent view.
Why?   well, eventually I see the musicbrowser as a
seperate program communicating with the zinf or other players.
This would allow us to evolve the components seperately.

Something to get the current URLs from the player
and something to let the set/get the current playing
song.

Again how would this co-exist would recursive playlists?
Should the current index be of the entire expanded list?
Just to be clear the player has it's own idea of a what 
a playlist is.. The current UI may have several playlists,
only one of which needs to be consistent with the player's.
For example:

Player playsheet
1.  file://song1.ogg
2.  file://myfavorites.m3u
3.  zinf://url?genre=ambient

While the UI may show:
1.  file://song1.ogg
2.  +file://myfavorites.m3u
3.     file://song2.ogg
        ...
99. +zinf://url?genre=ambient
       file://song10.ogg
       ...


The concept of index may not make too much sense
if we allow this.   However, URL's do not and should
not need to be unique (though I have seen a request
that there be option in the playlist to ignore
additional adds of the same song).   I am beginning
to think that a position should be a pair
(playsheet, index) or even modelled on a tree path.

Any ideas?

> 
> Or, are you suggesting that each playlist manager should have a single 
> playlist maintained internally (much like the current playlist manager) 
> and seperate instances are created for each playlist you want to edit. 
> Then reading metadata about a track is done through the playlist manager 
> as well, but it dosn't provide access to the underlying database so that 
> you can't query it for lists of artists or something.
> 
> Personally, even if the second option did provide a way to access the 
> library, it wouldn't make sense to be reading the library through what is 
> in affect a playlist. And if it didn't provide access to the library, you 
> would need to provide a seperate interface to read metadata from the 
> library. So in effect you would have two interfaces for reading metadata, 
> one for tracks in a playlist, and one for tracks only in the library. 
> Either way the second option doesn't seem like a particularly good idea.
> 
> The first option on the other hand, does seem like a good idea in theory, 
> as it would mean that all the musicbrowser or similar type ui would be 
> doing is implementing the playlist manager interface.
> 
> ...

[snipped]

> It has been mentioned that the whole database does not really need to be 
> read, taking up resources, if the current ui isn't even going to use. If 
> reading the entire database is less costly then reading it incrementelly 
> (on average), then how about doing a bit of both.
> No part of the database is read into memory until the first time a query 
> is made upon it, and this is when the entire database is read in. This 
> way, if the database is not used its never read, and if it is there is a 
> slightly costly first call on the database, then after that no extra cost 
> of reading anything from disk is incurred.


Whether loading the database is noticible if *very* dependent
on the machine you are running on.   My dually 1.8Ghz athlon
at work doesn't seem to mind loading it.  My 466Mhz P-III 
chokes on it for 20-30 seconds everytime I opened a new browser
(old design).   The important thing is that loading
of metadata should not be noticable.   Let's leave the
decisions of what should be loaded and when it should
be loaded in the database modules themselves.  For example,
look at the implementations of mdb/gdbmdatabase and mdb/mkdatabase
The gdbm needs to preload the entire db in order to support 
advanced queries..  You could change with a line or two
to cache the entries only on the first query.    


-- 
Kristian G. Kvilekval
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php