Re: metadatabase

On Wed, 15 Oct 2003 12:44:38 -0700, Kristian G. Kvilekval 
<[email protected]> wrote:

> On Wed, 2003-10-15 at 13:22, David Hough wrote:
>> On Wed, 15 Oct 2003 10:37:00 -0700, Kristian Kvilekval 
>> <[email protected]>
>> wrote:
>>
>> > On Wed, 2003-10-15 at 10:18, David Hough wrote:
>> ...
>> > Again how would this co-exist would recursive playlists?
>> > Should the current index be of the entire expanded list?
>> > Just to be clear the player has it's own idea of a what
>> > a playlist is.. The current UI may have several playlists,
>> > only one of which needs to be consistent with the player's.
>> > For example:
>> >
>> > Player playsheet
>> > 1.  file://song1.ogg
>> > 2.  file://myfavorites.m3u
>> > 3.  zinf://url?genre=ambient
>> >
>> > While the UI may show:
>> > 1.  file://song1.ogg
>> > 2.  +file://myfavorites.m3u
>> > 3.     file://song2.ogg
>> >         ...
>> > 99. +zinf://url?genre=ambient
>> >        file://song10.ogg
>> >        ...
>> >
>> >
>> > The concept of index may not make too much sense
>> > if we allow this.   However, URL's do not and should
>> > not need to be unique (though I have seen a request
>> > that there be option in the playlist to ignore
>> > additional adds of the same song).   I am beginning
>> > to think that a position should be a pair
>> > (playsheet, index) or even modelled on a tree path.
>> >
>> > Any ideas?
>>
>> I think the tree path is probably the best idea as abstractly thats a
>> reasonable model of what the playlist would actually be like if you
>> started allowing items to be expanded.
>
> So we need some sort of playlist iterator that actually
> represents a tree path..
>

This got me thinking exactly what functionality the 
browser/playlist-editor actually needs from any playlist interface and 
what functionality the base player needs. So I thought I'd have a go at 
setting down the minimum requirements for any playlist interface.

Internally the base player surely only needs these public interfaces:

get_current_track
move_to_next_track
move_to_previous_track

That is it, all other functionality is purely for the UI to manipulate the 
interface.

In terms of just a playlist object (ignoring the handling of multiple 
playlists, metadata, sorting, and loading/saving playlists) the UI needs

list_length
item_at
add_item(s)
remove_item(s)
move_item

set_current_position
get_current_position
(The current position functionality is special as it is only required for 
the current playlist, not all playlists.)

This is just a bare minimum of functionallity that any interface needs to 
provide to allow the use and manipulation of playlists. Exactly how this 
functionallity is actually implemented can be flexible, and extra helper 
functions would quite probably help keep code clean.

For instance the list_length, add_item, etc... could be implemented by 
having a function that returns a vector(void 
get_list_vector(vector<std::string>& list); or something like that). The 
UI would then edit this vector using the standard vector interface, then 
set the modified vector as the actual playslist (void 
set_list_vector(const vector<std::string>& list); for example). This would 
provide all the required functionality with out explicitly writing 
functions to do all of it. On the other hand you could implement exactly 
the functions I've mentioned as the current PlaylistManager class does.

When we got on to playlists with expandable playlist items as has been 
mentioned, the base functionality of the interface would need to change in 
only one way. A new function would be required so that the UI could expand 
an item and get the same result the playlist object would (e.g. void 
expand_item(std::string item, vector<std::string>& expanded_items);) This 
should mean that when the UI and the playlist communicate about position 
of an item, that is a child of an expanded item, they are actually talking 
about the same child. If the UI expanded items seperatly from the 
playlist, its possible that they might get different results or results in 
a different order, which would make the 2 represntations of the 
playlist(internal playlist object, ui list) out of sync.

As long as the vector type functionality (list_length, item_at, etc...) 
talked only about the unexpanded list there is no chance of the UI getting 
confused about how a particlur item is represnted in the base playlist. 
The implementation of the current_position functionality would have to 
change slightly to provide a way of talking about an item that is a child 
of another item(s).

The implementation of the current_position dosn't really have to be too 
complictaed, it could easily represnt a tree path as a simple vector of 
indexes at each depth, e.g. a vector containing 1,2,3 would mean the 3rd 
child of the 2nd child of the 1st unexpanded item in the playlist. I don't 
think we really need something as complicated as a tree path iterator to 
represent this, not even internally. The only place where this might be 
useful is in the move_next and move_prev functions which should be 
relatively simple functions even when talking about a tree path.

Has anyone else got any thoughts/ideas on this?

David

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


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com