Re: Requirements composed

David Hough <[email protected]> Wed, 29 Oct 2003 18:47:18 -0000
Newsgroups gmane.comp.audio.zinf.devel
Message-ID <[email protected]>
On Sun, 26 Oct 2003 21:44:35 +0100, Ralf Engels <[email protected]> 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.

It also needs to be possible to move items around in the playlist. This 
could be achieved by doing a remove and then insert instead of add at end, 
so perhaps
r2.1 it shall be possible to add songs at any place in the list

Or it could be done with a seperate requirement
r4. it shall be possible to move items 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
> r102. the meta data of the item shall be determined on demand
> r102.1 No data shall be duplicated.
> 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)

Would it not make sense to have a seperate set of requirments for the 
meta-database instead of specifing them in with the playlist item? And on 
the subject of implementation surely it would be simpler to use the actual 
database of metadata instead of caching this data in the playlist, or are 
you assuming that this would be too much of a performance hit?

> 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)
> r105. Metadata should only be read from an external source on demand
> (why, what is an external source?)
> r106. It should be possible to do searchs on cached metadata
> (search for what, what for?)
>

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


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