Requiurements next try

Hi,
included all the latest comments. Still not clarified if we should have 
a list or a tree of songs.


By the way, Ed, you were right about the URI and we both didn't 
understand each other.
Of cause you will index the song by it's position in the playlist.
But the URI is still the primary identifier of the song, e.g. having 
URIs in the songlist is sufficient.
Please see r1 and r1.1


Requirements for Playlist handling in zinf.
Sub-requirements are denoted with a point e.g. 3.1
Technical requirements are with two point 3.3.3


r1. there shall be a list with songs
*** Big question: should this be a tree of songs? please vote
*** This was still not clarified. Should we have a tree?
*** One vote for no from ralf
r1.1 If we have a list then the songs in the list can be identified by 
their position in the list.
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
r3. it shall be possible to remove songs in the list.
r4. the list shall be independent of the ui
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
r6  It shall be possible to select the next song in different ways
r6.1 It shall be possible to set this way
r6.2 it shall be possible to set way by filename
r6.3  by path
r6.4  by songname
r6.5  by artist
r6.6  by album
r6.7  by year
r6.8  by random
r7. the player shall use the list to determine the next song to be played.
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
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
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
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 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
(I don't want to write a technical requirement for this (Ralf))
r105. Metadata should only be read from an external source on demand




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