Re: Requiurements next try

On Thu, 2003-10-30 at 07:02, Ralf Engels wrote:
> 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
> 

Please break these into 
1. player requirements
2. UI requirements (we have several ui, some do no 
   playlist management at all)
3. metadata requirements


> 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.  Might read: " the player will accept playlists (possibly
recursive)"

> r1.1 If we have a list then the songs in the list can be identified by
> their position in the list.
For what purpose? Strike requirement or make clear the context.

> r2. it shall be possible to add songs to the list.
UI requirement 
> r2.1 it shall be possible to add the same song multiple times to the list
player list requirement
> r2.2 it shall be possible to add songs at an arbitrary position in the list
UI
> r3. it shall be possible to remove songs in the list.
UI
> r4. the list shall be independent of the ui
> r5. the ui shall be informed about changes in the list
How about playerlist will support position queries (and support
asynchronous notifications).
> r5.1.1  the list shall send events to registered listeners
Implementation requirement
> r5.1.2  the list shall not transmit pointers with the events
Ditto
>r6  It shall be possible to select the next song in different ways
UI requirements
> 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
All of these can be summed up as "selection through valid metadata"

> r7. the player shall use the list to determine the next song to be played.
> r8. it shall be possible to save the list
UI
> r9. it shall be possible to load the list
UI  (also should read edit a playlist that is not currently playing).
> r10. different formats for the playlist shall be supported
> r11. It shall be possible to dynamically generate lists (how?)
Using the metadata database (add a zinf url i.e. zinf://url?genre=blues)
> r13. The base-code shall support the ui when it want's to display a list 
> of songs
What?
> r13.1  There shall be different views on the playlist, e.g. by album, 
> sorted, ...
UI
> r13.2 The code shall support the ui moving items around
UI
> r13.3 The code shall support the ui searching for meta information
UI
> 
> 
> 
> Playlist item requirements
> r101. the URI shall be the unique identifier of an item. URI is full 
> qualifyer data like file://hallo.mp3

There is a problem when dealing with CD tracks this way, since 
all of them are currently labelled as "file://1.cda"...
We might get around this using TRM IDs evenutally.

> r102. the meta data of the item shall be determined on demand

How about "the most current metadata will be used"

> r102.1 No data shall be duplicated.
>        This is really a general rule for programming.

To general, caching is good thing as long as it's consistent

> 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

In the new metadata system, we copy reference counted string around
quite a bit.    Since these are already sharing storage, I don't think
it's necessary to add another layer of ref-counting.

> 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)
  And n is what? The size of the database?   How about when used
with the music brainz database.
> r102.1.8 A map shall be used for meta-database O(log n)

A map interface map(url) -> metadata or map(metatag) -> data??

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

See early mails "music catalog overhaul"

> r105. Metadata should only be read from an external source on demand

Or at least from a consistent cache.


-- 
Kristian G. Kvilekval
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



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