Re: metadatabase

You must love to overcomplicate things

You're going to create a playlist Object which is just a list so why not 
operate on list directly? And what type is url_t, why obfuscate things?


And what you've basically done is what i've done but each iteration of 
the root playlist is another list.  This makes moving streams around 
problematic. You also have to recreate your own insert and remove etc 
methods.  Mine are STL's, so they're pretty much guaranteed to not have 
bugs introduced by me.   And for what?  The only gain your 
implimentation has over mine is it indexes the branches, other than that 
there are none. and I could achieve indexes by just adding a vector of 
Playlist pointers, which are set to the Playlist objects that are 
playlists. This would give me everything yours has plus my check for 
when i need to dive into a branch is a simple (if(playlists)) where as 
you have to search the string for all valid playlist prefixes or 
extensions every single time you traverse the tree.  This can get to be 
quite a noticable difference given a simple tree of a thousand or so 
songs.


But all this really just solidifies this fact.

your mission to make playlist management based on URI's alone wont work. 
   A UI with just a list of URI's has no way of telling the playlist 
manager where in the playlist it actually is. You have to include an 
index (corresponding to the list of branches) of where to start looking 
and then an index of the stream within that branch.  URI's just wont 
work, they're too restrictive.  It means you cant populate a list with 
more than one instance of a stream in a single branch and this is just 
dumb. Sorry, but even with a flat list and no sort of branching going 
on, playlists based on URI's wont work unless you limit the 
functionality of the playlist.  Basing the playlist on two indexes makes 
more sense anyway, and it should be a lot faster to process two ints 
than doing a lot of string comparisons.




Kristian G. Kvilekval wrote:
> On Sun, 2003-10-19 at 11:08, David Hough wrote:
> 
>>On Fri, 17 Oct 2003 20:21:51 -0400, Ed Sweetman <[email protected]> 
>>wrote:
> 
> 
> [snipped]
> 
> 
>>As far as I can tell your implementation dosen't provide a simple way of 
>>viewing the entire expanded playlist as a single flat list which is a view 
>>that will be needed. Personally I think the list should be represented by 
>>a map of URLs with a tree path as the key, something like this quick 
>>example:
>>
>>class Playlist {
>>	std::vector<std::string> base_list;
>>	std::map< std::vector<uint32_t>, std::string > expanded_list;
>>	
>>	void generate_expanded_list();
>>	void read_children(std::vector<uint32_t>& parent_path, 
>>std::vector<std::string>& urls);
>>};
>>
>>The base list would be the list of original URLs for the playlist, and the 
>>expanded list would be a list of tracks that were expanded from the base 
>>list. This way you can do simple random access to tree by just reading the 
>>URL associated with a path from the map, and the playlist manager can move 
>>through the playlist using an iterator on the map.
> 
> 
> This is a start, but I see trouble.  The base playlist is the top level
> set of unexpanded URL.   The expanded list is the full tree.   
> There doesn't seem to allow  access to the simple set of
> a sublist or is that what read_children does?
> 
> Also I don't think it a good idea to try to keep a map of what
> are essentially iterator values to the elements.   Let's try to model
> what we have: a tree of playlists.   Each node is playable item,
> some nodes are expandable.   We then provide access to the tree
> using whatever path structure make sense.
> 
> 
>>The UI could read the base urls and then get specific children from the 
>>expanded list using the read_children function. This way the UI would 
>>always be in sync with the playlist as it would be reading the children 
>>directly from the playlists own expanded view.
>>
>>This interface does provide both a tree view of the playlist and flat 
>>view. The flat view would just be the std::strings in the map, and the 
>>tree view is implemented by having a tree path asssociated with each url. 
>>I haven't got around to writing an example implementation of this class, 
>>but I would expect that the algorithms needed wouldn't be that 
>>complicated.
> 
> 
> Again I think the data structures should model the concepts more
> closely.
> 
> 
> class playlist {
>     std::list<url_t>   m_urls;
>     // Simple functionality on a flat playlist (wrapper for list)
> };
> 
> 
> class playlist_tree_iterator ;    //vector of  indexes 
> class playlist_tree  {
>     playlist   m_root;
>     // Path based routines.
>     insert (playlist_tree_iterator  path, url_t) 
>     erase (....)
> 
>     playlist&  root_playlist()
>     plalist_tree_iterator currentItem();
> };
> 
> All the machinery for dealing with recursive playlist would be maintained
> in the playlist tree.   The editor would probably often need to only deal with 
> the simple playlist (the UI would choose which is the current simple playlist).
> The player would see playlist_tree as a set of simple playlists and 
> playlist_tree_iterators.
> 
> I would like to be able to say something like:
>  playlist_tree a;
>  vector<url_t> list;
>  copy(a.begin(), a.end(), inserter(list, list.begin()));
> which would give a flat list of urls in the vector.
> 
> 
> We also need to expand the concept of random play mode in the player.  Let's say
> I have recursive playlist made up of albums of artist X.   I want the 
> albums to play in random order but not the songs or vice versa.  
> Each level in the hierarchy will need some sort of play mode
> in the player.  
> But I digress..
> 
> 




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