Re: Playlist requirements

On Sun, 19 Oct 2003 19:52:36 +0200, Ralf Engels <[email protected]> wrote:

> Hi,
> seems like I started a big discussion with my mail about the database.
> I have a proposal. One shortcomming of the open source development is 
> that it doesn't use some kind of process.
> I want to propose something.
> Let's collect this week all requirement that we have for the playlist. 
> Just send your requirements and we will collect them at the end of the 
> week.
> Maybe Kristian can filter them on Friday.
>
> Next week we will fill it out with hard technical requirements (e.g. 
> Playlist class needs search)
> and after that make the required changes.
> In this way we can be sure that we all agree what we want, and that 
> nothing will be forgotten. Additional we only needed things will be 
> kept. Code that we don't need any more can be removed.


I agree, this seems a reasonable way to go about creating a new 
playlist/metadata structure in a well designed way. Lets wait until we 
have a full and agreeded upon specification before we go about working out 
how to implement it. So here's some quick ideas from me:


> Ok, so I start with my requirements:
>
> r1. there shall be a list with songs that can be played.
> 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
> r6. it shall be possible to randomize the list (I don't need a random 
> play as long as I can shuffle the list)

  r6.1 it shall be possible to switch back to a unrandomized list while 
maintaining current position in playlist (equivalent of turning random 
play off while listining to a playlist)


> 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
>
> Playlist item requirements
> r101. the URL shall be the unique identifier of an item
> r102. the meta data of the item shall be determined on demand
> r102.1 meta data of items with the same URL shall not be doublicated

  r103. items should be able to change depending upon the contents of music 
catalog (i.e. dynamic playlist)


> Music catalog requirements
> r201 ?? I don't need such a thing.

  r201. Metadata about URLs should be cached
  r202. It should be possible to read metadata from various sources
  r203. Metadata should only be read from an external source on demand
  r204. It should be possible to do searchs on cached metadata


> Ok, that is just the start. Other can continue with the list.
>
> BR,
> Ralf

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


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54