goals vs requirements

In the past I have suggested these goals as a way of
guideing development.  I thought I would reiterate them
as we are discussing requirements:  Just for perusing.

1.  Make the player code independent from the UI.

    This would allow the UI and player to be developed seperately 
    and might allow use to substitute the player core as it becomes
    to old to support newer formats.   This would entail
    removing shared datastructures between the UI and the player.
    Using a simple list of URLs seemed like an appropiate datastructure
    at the time.   Loading a new playlist into the player would 
    be as simple as sending it a list of URLs to play (something
    like launching the player from command line).

    As strings are relatively cheap, the player could also send 
    the UI it's active list of URL's (playlist) and an index
    to indicate what it's currently playing.   

    These communications could be accomplished through a private
    channel (a socket, clipboard, or IPC, or even stdin/stdout).
    With stdin/stdout you could imagine the player actually
    running a text mode UI and recieving/reporting commands from/to
    the music browser running in a seperate process.


2.  Build a better/flexible metadata system

    Here the idea was to allow different users to use
    different levels of metadata.  A layered metadata
    model combining different sources of metadata (filenames, tags,
    web databases).     These sources were to be configurable.
    Some people want no metadata, others want alot.
    Another sub-goal was to allow arbitrary
    querying of metadata (i.e. tell me all songs that have 
    the same genre, beat pattern, artist).  
    Another sub-goal was to keep metadata out of player and the
    UI.. each component would simply make request to the metadata
    system to fill in the appropiate metadata.

    The mdb code is an initial stab in this   
    direction.  It still needs to be better integrated
    and  several modules need to be finished off (musicbrainz, plugins).
    
3.  Explore the concept of recursive playlists.

    Recursive playlists are and extension of the basic
    playlist mechanisms (m3u, pls files) to allow subplaylists
    to be played in line.    Using zinf meta URLs, they
    could also be used to generate dynamic lists of songs
    based on the current contents of the users music database (see    
    above).

    No other players really have this so maybe it's not
    the best idea,  but it seems pretty cool.   I think
    the basic system should support flat playlists
    possible adding the recursive playlists later.   


Design decisions:

1.  Make zinf two sub-projects (player vs. musicbrowser)

    This is taking a back burner for now.   No solid reason
    to do this other than the player core is creaking a little bit.
    However,  with new development I think this should be taken
    into consideration.   For this reason new data structures
    are being designed to be "channel friendly" i.e. they
    are trivial to serialize.


2.  MDB integration

    This is my main concern right now.   It should be fast
    even on slow machines (like mine) and not need a lot
    of code (take a look at the interaction between the old
    base/src/musiccatalog and ui/musicbrowser/unix/src/* )
    to maintain a consistent database.     The new model
     simpler and has more functionality.

3.  Flat or recursive (tastes great! Less Filling)

    I think the next version of zinf will probably have 
    flat lists unless someone really starts to develop
    this.  Eventually I would like to see this happen.

-- 
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.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/