Re: metadatabase

On Tue, 2003-10-14 at 11:34, David Hough wrote:
> On Mon, 13 Oct 2003 01:24:32 -0400, Ed Sweetman <[email protected]> 
> wrote:
> 

> Gutting a lot of the old code and starting a new branch would indeed make 
> a lot of sense. There appears to be large amounts of code that isn't used 
> at all, or is replicated somewhere else. It would also allow large changes 
> to be made without having to ensure compatability with old code.

Please make sure nothing uses the code..   Cleanup is a good thing,
we've managed to not have win32 buildable for over a year after
the last "cleanup".  We are still trying to recover.

> >
> > So yea, lets see some definitions and specifications on what a playlist 
> > should be, why does it have to be different from a metadata manager and 
> >   under what method should the UI be hooked into the whole thing and 
> > anything else relating to it.
> >
> > to me :
> >
> > Playlist: human readable text list of streams playable to the the player
> > Playlist Manager: container that creates a list in the player consisting 
> > of translated playlist entries such that a UI can correctly display the 
> > entries.
> > metadata manager: container that retrieves, accesses, removes, and 
> > possibly writes metadata related to lists of streams given to it.
> >
> >
> > Playlist would be an object or array of objects private to Playlist 
> > Manager.  Metadata manager would be inherited by Playlist Manager. Such 
> > that say to get the current track to be played you'd have a call to the 
> > Playlist manager like 
> > playlistManager->getStream("file:///home/mysong.ogg"); Retrieving 
> > metadata if available is taken care of implicitly by getStream by simply 
> > calling this->metaManager->getStream("file:///home/mysong.ogg"); which 
> > only accesses the database.  A separate update method can be used in 
> > metadata Manager to update entries in the database as opposed to 
> > researching directories for files and such and adding them to the 
> > database.  These should be done explicitly by the user and not used when 
> > simply reading the db for displaying a playlist.   etc etc.  Some 
> > feedback would be cool.
> 
> Personally, I don't reckon the playlist manager should be concerned with 
> metadata at all. The playlist manager should be concerned with providing a 
> way to move about in a playlist (next, prev, set index, etc...) and 
> providing the player with a url for the current track.  The playlist 
> manager should also provide an interface for manipulating a playlist (add, 
> remove, move, etc...) that will be accessed by the playist editing UI.
> 
> There is no reason why the playlist manager should ever need to know 
> metadata about any url as far as I can see, so it dosn't make sense (to me 
> at least) that metadata should be read through the playlist manager. As 
> far as I know the player itself never needs to know any metadata about a 
> track, it just plays it. The only place metadata becomes relevant is in 
> the ui plugins, so why mix the metadata in with basic player 
> functionallity (i.e. playling a playlist)?

I certainly agree.  I prefer the playlist to manipulate a list
of URLs and nothing else.   Both the player and UI can retrieve 
needed metadata on demand.  However, There are a few utility functions
that don't seem fit elsewhere (i.e. total playlist time).
I certainly don't want the playlist to cache metadata.

However, we should still discuss the concept of recursive playlists
as I alluded to in my previous posts.
Here the base playlist type should simply be a list of URLs.   The
player and the UI should be responsible for sensibly
expanding recursive playlists.


> I reckon the metadata manager should be completey seperate from the other 
> base functionality of zinf as all it is doing is providing data to 
> possible UIs, it is never actually used to play tracks. This is also part 
> of the argument for not loading the entire metadata database at startup in 
> the base section of zinf as there is no guarentee that it will be actually 
> needed by the UIs, although it is highly likely.

Yes!  I hope eventually to completely disassociate the music/metadata
browser from the player as they accomplish different goals. I think they
should communicate through some sort of messages rather than direct
calls.

The metadata systems could then be used independently by each. 


> Anyway, thats just my opinion, feel free to pick holes in my reasoning if 
> there are any.
> 
> David
-- 
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