Re: Requirements composed

Ralf Engels wrote:
> Hi,
> I have written all the requirements together and added technical 
> requirements where usefull.
> Sadly there where much discussions about "how to do it" when the "what 
> to do" was not fixed.
> So, I would say that we should agree first on the requirement list and 
> then someone can propose a design (based on the current design).
> 
> So, here goes the list:
> 
> 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
> r2. it shall be possible to add songs to 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.1  There shall be different views on the playlist, e.g. by album, 
> sorted, ...
> 
> 
> 
> Playlist item requirements
> r101. the URI shall be the unique identifier of an item. URI is full 
> qualifyer like file://hallo.mp3
completely ignores the fact that i can add the same track twice in the 
playlist.  How is the URI supposed to be unique for that? Are you going 
to make zinf not support multiple iterations of the same track? That's 
stupid, not in just my opinion, but just about every player i've used 
allows multiple instances of the same track name.

Two tracks
file:///this/is/another/track.mp3
file:///this/is/another/track.mp3

How do i tell the playlist to remove the second one if i just do things 
like playlist-manager.remove("file:///this/is/another/track.mp3");

You cant. URI's are not unique in the same branch.

> r102. the meta data of the item shall be determined on demand
> r102.1 No data shall be duplicated.
should be specified where this occurs.  You're not allowed to pass 
pointers back to the Ui so obviously, the Ui is going to have to copy 
the data in the playlist manager. I believe the playlist should recieve 
pointers since it makes no sense to copy that data but it should be in a 
read-only manner.  Likely though, that wont be feasible.

> r102.1 (logical extension) meta data of items with the same URL shall 
> not be doublicated
> 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)
> 
> 
> To be clarified
> r104. It should be possible to read metadata from various sources
> (what sources are meant)

files, online databases.

> r105. Metadata should only be read from an external source on demand
> (why, what is an external source?)

external is outside the database.

> r106. It should be possible to do searchs on cached metadata
> (search for what, what for?)
> 

search for any particular metadata field, for use in the UI.




-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/