Re: goals vs requirements

Ralf Engels wrote:
> Hi,
> I can understand both points of view.
> 
> I don't want to heat the flames. Just hold on a little bit more. I am 
> now going to write technical requirements in the document. If you 
> participate both we can come to a solution that both of you dislike 
> equally :)

well, I dont really have any say. I started this discussion as much to 
get zinf developed in the intended direction as much as for my own 
development player to go in the right direction.  If Kristian can give 
an argument stronger than my own for having the UI do what he wants it 
to do or somehow show me that i'm mis-interpreting what he's saying then 
i'll give in. But from everything said up until now, I dont think that's 
going to be the case.


> Kristian, what I mean with Metadatabase is exactly what you want to do 
> with mdb but I still don't know why you are not saving the metadata e.g. 
> with the playlist. Please write your requirements. Only 102.1.2 and 
> 102.1.3 are mandatory for me.
> 
> Ed, I updated the requirement and stated that the playlist shall be 
> independent of the player. This would move the task of selecting a new 
> song to the player which sounds much better to me. How about if you fill 
> out the player requirements?

with the player in charge, playing songs is not done by the UI sending a 
track or index to play. Rather it calls functions in the playlist 
manager to play sequentially (normal playback), play random, loop 
playback and all other arbituary types of playback. The player then 
makes it available to the player what song is currently being played. 
The UI doesn't need to communicate back to the player until the mode of 
playback is changed.  The only time the ui needs to communicate a 
specific track is when the user manually skips to a certain track, in 
which case how it does this is dependendent on the type of playlist 
agreed upon.


I'm in no position to make player requirements, but if i were to make 
any hard requirements to the player regarding arbitrating data between 
the UI and playlist manager I would make them these:

r208   Player must be able to give ui sufficient playback information 
regarding current track and position in playlist


on second thought.   I think all of these ideas of multiple subsystems 
being altered is a bit far reaching. Development on zinf is going to be 
hard enough to get one subsystem working correctly without having 
numerous hacks to get it to work around all the other broken systems. I 
think first the interface between the UI and player/playlist manager 
needs to be fixed (if it doesn't strictly work this way already) to not 
feed the player a stream everytime it goes to play the next track.. The 
player shouldn't be spoon fed by the UI, it should be able to go into an 
autopilot given a type of playback mode command by the UI. Once that's 
done, the playlist/playlist manager can be changed without worrying 
about later modifying it all so that it works with the player 
controlling the playlist. Metadata can then be coded around the way the 
playlist/playlist manager works.   I think that way you get much 
rewriting of what you just got done writing, with a more easily 
debuggable development route to go intsead of doing it all at once.




> Please hold on, let us continue with it and we will have the best design 
> a music-player ever had.
> 
> So here is the updated list with some technical requirements added
> 
> r1. there shall be a list with songs.
> r1.1 the list shall include sub-lists
> r1.1.1 There shall be a object called PlaylistItem
> r1.1.2 There shall be a object called Playlist with sub-classes 
> PlaylistItem
> r1.1.3 The Playlist object shall manage a std::vector of PlaylistItems
> r1.1.4 The Playlist object shall have a function GetItem( int pos ) 
> which returns the PlaylistItem at the position.
> r1.1.5 The PlaylistItem shall have a function called GetURL which 
> returns the URL of the item
> r2. it shall be possible to add songs to the list.
> r2.1 it shall be possible to add the same song multiple times to the list
> r2.2 it shall be possible to add songs at an arbitrary position in the list
> r2.2.1 The Playlist shall have a function InsertItems( 
> std::vector<PlaylistItems>, int pos )
> r3. it shall be possible to remove songs in the list.
> r3.1.1 The Playlist shall have a function RemoveItems( int pos, int length)
> r4. the list shall be independent of the ui and the player
> r4.1.1 There shall be an object called PlaylistInterface which does 
> UI-dependent operations on the Playlist
> r5. the ui shall be informed about changes in the list
> r5.1.1  the list shall send events to registered listeners
> r5.1.2  the list shall not transmit pointers with the events
> r5.1.2  There shall be an event called PlaylistChanged
> r8. it shall be possible to save the list
> r9. it shall be possible to load the list
> r10. different formats for the playlist shall be supported
> r10.1.1. There shall be an object called PlaylistFormatManager (I 
> already have written this (Ralf))
> r10.1.2. The playlist format manager shall have a function called Error 
> PlaylistFormatManager::LoadPlaylist( std::string URL, Playlist* playlist 
> ) const
> r10.1.3. The playlist format manager shall have a function called Error 
> SavePlaylist( std::string URL, Playlist ) const
> r10.1.4. The playlist format manager shall use loadable PlaylistFormat 
> object to do the actual loading and saving
> r11. It shall be possible to dynamically generate lists (how?)
> r13. The base-code shall support the ui when it want's to display a list 
> of songs
> r13.1  There shall be different views on the playlist, e.g. by album, 
> sorted, ...
> r13.2 The code shall support the ui moving items around
> r13.3 The code shall support the ui searching for meta information
> 
> 
> 
> 
> Playlist item requirements
> r101. the URI shall be the unique identifier of an item. URI is full 
> qualifyer data like file://hallo.mp3 instead for CD-tracks
> r102. the meta data of the item shall be determined on demand
> r102.1 No data shall be duplicated.
>       This is really a general rule for programming.
> r102.1 (logical extension) meta data of items with the same URL shall 
> not be doublicated
> 
> 
> Metadatabase mdb
> r102.1.1 We shall have a meta-database
> r102.1.2 The meta-database shall have a function getMeta( string URI )
> r102.1.3 The meta-database shall have a function setMeta( string URI )
> r102.1.4 The meta-database shall have a reference count so that unused 
> metas can be deleted
> r102.1.5 The meta-database shall have a function refereMeta( string URI )
> r102.1.6 The meta-database shall have a function unrefereMeta( string URI )
> r102.1.7 All operations on the meta-database should be faster or equal 
> then O(n)
> r102.1.8 A std::map shall be used for meta-database O(log n)
> r103.  Playlist items should be able to reference other playlists 
> inline.  (i.edynamic playlists)
> r104. It should be possible to read metadata from various sources e.g. 
> musicbrainz
> (I don't want to write a technical requirement for this (Ralf))
> r105. Metadata should only be read from an external source on demand
> 
> 
> Player
> r201. The player shall select the song to be played and play it.
> r202. The player shall send events with position update
> r206  It shall be possible to select the next song in different ways
> r206.1 It shall be possible to set this way
> r206.2 it shall be possible to set way by filename
> r206.3  by path
> r206.4  by songname
> r206.5  by artist
> r206.6  by album
> r206.7  by year
> r206.8  by random
> r207. the player shall use the list to determine the next song to be 
> played.
> 




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