Re:Re: goals vs requirements

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 :)

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?

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/