Re: Playlist requirements

Kristian Kvilekval wrote:
> On Sat, 2003-10-25 at 11:46, David Hough wrote:
> 
>>On Sat, 25 Oct 2003 17:55:26 +0100, Robert Hart <[email protected]> 
>>wrote:
>>
>>
>>>On Sat, 2003-10-25 at 18:40, David Hough wrote:
>>>
>>>
>>>>I still believe that the metadata interface should be seperate from the
>>>>playlist/playlist manager as there is no reason why the playlist needs 
>>>>to
>>>>now any metadata about any url, apart from its child urls.
>>>
>>>I'm confused, you talk about the playlist being able to sort/randomise
>>>according to things like "Album", "Artist", (and by inference) date,
>>>genre, etc.
>>>
>>>Yet at the same time you seem to be saying that the playlist wont "know"
>>>this information....
>>>
>>
>>Thats a very good point. I hadn't considered exactly how such a randomise 
>>feature would be implemented. The point I was trying to get across though 
>>was why cache metadata in the playlist memory structure, when its much 
>>easier and uses less memory to just read it from the database/metadata 
>>catalog when its needed. And if you're just going to read the metadata on 
>>demand (usually on demand of the UI, although in the point you made it 
>>wouldn't always be from the UI) why confuse the playlist manager interface 
>>by having external functionality that has very little to do with playing a 
>>list of URLs.
>>
>>So, I was probably wrong to say that the playlist manager never needs to 
>>know this information, however just because it may actually need it 
>>internally occasionaly, does not mean that it should be used to provide 
>>the metadata interface.
> 
> 
> 
> I suggest keeping the static state of the playlist (the list of URL's)o
> different from the dynamic state of the playlist player i.e. the 
> current index, playmode (repeat etc), randomize, etc.   
> 
> The basic functionality common to all playlists is the list of
> urls functionality.     The next level of functionality is the 
> ability to interpret recursive playlists.  And finally, there
> is the dynamic level or the player playlist functionality.   
> 
> The UI is probably interesting in the base/recursive level.
> While the player would have all sorts of other information.
> 
> I see a hierarchy of playlists types or even keeping the 
> player (dynamic) info in the player itself.
> 
Nobody is debating the fact that there should be a class for the list 
itself and a container class that commands the list.  The point is to 
take as much functionality dealing with manipulation of information in 
the player away from the UI because it doesn't belong there.  The ui 
renders info it recieves, it should not be processing that information 
to create new functionality, or rather that should be very limited. It 
will cause a weak code architecture and means duplication of code 
functionality across all toolkits. I'm fairly sure you dont mean that so 
everything you've basically said here nobody is debating.


The last part though is something like i've implimented in my player 
already, although mine is a bit different.  An object that acts as the 
communication class across all subsystems, containing the run-state and 
all preferences and such of the entire player.  It lets me get around 
corner cases where a subsystem needs to know something about another 
subsystem but cannot speak directly because of heirarchy.  It also means 
i can create a vector of players each independent of eachother... which 
is pretty neat.   Something like what you want though, that kept all 
dynamic info of the player for would be a pretty big rewrite.



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