Re: Re:Re: goals vs requirements

On Fri, 2003-10-31 at 08:59, Ralf Engels wrote:
> Hi,
> I can understand both points of view.
> 
> I don't want to heat the flames. Just hold on a little bit more. I am 
> now going to write technical requirements in the document. If you 
> participate both we can come to a solution that both of you dislike 
> equally :)
> 
> Kristian, what I mean with Metadatabase is exactly what you want to do 
> with mdb but I still don't know why you are not saving the metadata e.g. 
> with the playlist. Please write your requirements. Only 102.1.2 and 
> 102.1.3 are mandatory for me.

It has to do with simplicty and cache consistency.   Once the metadata
is loaded into the playlist  changes to the metadata must be updated
in both the metadata database and the playlist items.   The simpler
rule is that items always query the meta catalog system (which may
cache).

This was extreme in the previous incarnation of the browser
metadata had to be synchronized in three places:  the metacatalog, the
playlist, and browser display.  Unfortunately, this was difficult to
do and there's lots of code to prove this.   If both the player
and browser simply query the metacatalog (again.. it can cache
results..see cachedb) whenever the are about to display some
metadata, we don't need to worry about consistency.   Every
write of metadata goes to catalog, every read of metadata
comes from the catalog.  In the musicbrowsermm when 
items get refreshed they just read the musiccatalog.  In this
way the musiccatalog has no need to send update commands all
over the place.   You can think of also as saying we are moving
to pull-model of data distribution.


> Ed, I updated the requirement and stated that the playlist shall be 
> independent of the player. This would move the task of selecting a new 
> song to the player which sounds much better to me. How about if you fill 
> out the player requirements?
> 
> Please hold on, let us continue with it and we will have the best design 
> a music-player ever had.
> 
> So here is the updated list with some technical requirements added
> 
> r1. there shall be a list with songs.
> r1.1 the list shall include sub-lists
> r1.1.1 There shall be a object called PlaylistItem

See above.. 

> r1.1.2 There shall be a object called Playlist with sub-classes PlaylistItem
> r1.1.3 The Playlist object shall manage a std::vector of PlaylistItems
> r1.1.4 The Playlist object shall have a function GetItem( int pos ) 
> which returns the PlaylistItem at the position.
> r1.1.5 The PlaylistItem shall have a function called GetURL which 
> returns the URL of the item
> 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

Somehow this issue has become clouded.   Somehow it seems that somebody
misinterpreted my statement about uniqueness of URLs.
URLs are unique keys to the metacatalog system.   They are not unique
keys to playlist entries.   An index is the unique key to a playlist.  
This index may be simple integer or a path (if recursive playlist are
implemented).


> r2.2 it shall be possible to add songs at an arbitrary position in the list
> r2.2.1 The Playlist shall have a function InsertItems( 
> std::vector<PlaylistItems>, int pos )
> r3. it shall be possible to remove songs in the list.
> r3.1.1 The Playlist shall have a function RemoveItems( int pos, int length)
> r4. the list shall be independent of the ui and the player
> r4.1.1 There shall be an object called PlaylistInterface which does 
> UI-dependent operations on the Playlist
> 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
> r5.1.2  There shall be an event called PlaylistChanged

I have to disagree with these points.   Imagine, if you will for the
moment, three servers:  player, browser, and catalog.
These servers communicate through a simple message system.   As I
mentioned in my previous email, we should simplify the interface between
these components to their minimum.   Currently the music catalog simply
read/writes sets of tagged strings i.e.  send it a URL it will send you
back a map of metadata.    It would be fairly simply to wrap these in 
message transport.   There is no need now, but it also makes using the
components simpler. 

The player could also be simplified to accept/notify simple commands
back and forth to/from the browser.   At some point, I would like
to be able to DragNDrop a list of URLs into the browser or the player
and have it just work.    At the root of all this was a design goal to
minimize  cross-dependencies between  the major components
(player,browser, catalog).   If both the player and the browser have to
know (i.e. have a pointer to ) about the "player playlist" and
understand what player playlist-items are, it just makes working
on one component that much harder.  

Finally, whether the player playlist decides to keep a copy of the
metadata for it's own purposes is really beside the point.   My
suggestion  is that it is best to consider the player, browser, catalog
as separate  systems and minimize the implicit sharing of data.   One
way to  do this is to rely on very simple types (strings, list of
strings) to communicate between components.    


> 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
> r10.1.1. There shall be an object called PlaylistFormatManager (I 
> already have written this (Ralf))
> r10.1.2. The playlist format manager shall have a function called Error 
> PlaylistFormatManager::LoadPlaylist( std::string URL, Playlist* playlist 
> ) const
> r10.1.3. The playlist format manager shall have a function called Error 
> SavePlaylist( std::string URL, Playlist ) const
> r10.1.4. The playlist format manager shall use loadable PlaylistFormat 
> object to do the actual loading and saving
> 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 instead for CD-tracks
> 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 mdb
> 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 std::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 e.g. 
> musicbrainz
> (I don't want to write a technical requirement for this (Ralf))
> r105. Metadata should only be read from an external source on demand
> 
> 
> Player
> r201. The player shall select the song to be played and play it.
> r202. The player shall send events with position update
> r206  It shall be possible to select the next song in different ways
> r206.1 It shall be possible to set this way
> r206.2 it shall be possible to set way by filename
> r206.3  by path
> r206.4  by songname
> r206.5  by artist
> r206.6  by album
> r206.7  by year
> r206.8  by random
> r207. the player shall use the list to determine the next song to be played.
> 
The player really needs to know how to play list of songs .. how the
list get chosen is really the browsers domain.    

I really like to think of the player component as nothing more than
a fancy ogg123 command line player.   The browser feeds the player
with URLs based on user manipulations and metadata.

okdioki.  



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