Re: goals vs requirements

Kristian Kvilekval wrote:
> 
> 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.   
>


I'm pretty sure i see now the major difference in opinion of what a 
playlist manager and UI and player should be.  You believe the UI 
controls the real playlist, where as the player is just given a list of 
all the different tracks the UI wants to play in order to get required 
data about the tracks.  (this is the only way URI's can be used as a 
unique identifier in the player, because the player doesn't care about 
order in your method)

I believe the UI should have as little to do with the function of the 
program as absolutely possible. Meaning the player sends the UI a list 
of what is going to be played and it displays that list to the user in 
any arbituary way.  The UI tells the player what to load, and it can 
tell it what to alter, but it's the player that holds the real list, not 
the UI.

In your method, URI's are perfectly fine for all communication to the 
player, because the indexing is carried out in the UI, when someone 
points to a uri in the list and hits delete, it's deleted because the 
index to that selected stream is done by the toolkit, the player really 
doesn't come into the picture except maybe to remove uneeded metadata.

I believe your method is flawed, for that very reason.  By having the UI 
hold the real list instead of recieving that list from the player, you 
are forcing some integral functionality, into the UI, which is toolkit 
based. This means having zinf under any different toolkits requires 
copying that functionality over and it may not always be possible to do 
it the same way.  It also cripples zinf modularity.  Very very bad.

My method would have zinf be completely independent of a UI, all of the 
playlist,metadata and etc functionality is within the player.  The 
advantages to such a setup are fairly obvious i think and this is not 
what you're suggesting with this URI communication setup.


>     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.   

believe it or not, zinf has the most comprehensive playlist manager out 
of just about all players, already. It's really had ideas from it copied 
in other players and really it's probably the major reason why anyone 
uses zinf given it's lack of codec support for other popular formats, 
lack of visual plugins for the eye candy kiddies, sub-to-par speed 
performance, and crazy ass UI with only half the program skinned. The 
playlist is what makes zinf, zinf right now. And my point is, going 
where nobody else is seems to be a win/win situation.



> 
> 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.
> 




-------------------------------------------------------
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/