[vlc-devel] playlist: flat / tree separation

[Rémi Denis-Courmont]

Le samedi 22 août 2009 02:47:11 Jean-Baptiste Kempf, vous avez écrit :
> Hello,
>
> On Fri, Aug 21, 2009 at 02:43:07PM +0200, Jakob Leben wrote :
> > Any thoughts very welcome, please.
>
> Let's try to sum up a few things from a user PoV:
>  - Playlists are playlists, and people want to sort and rearrange
>    them... Which is difficult to do in a tree-view.

It's not difficult. It's impossible in a understandable way. How do you order 
a tree alphabetically or randomly? It simply cannot work. Indeed, if the tree 
were randomized without first being flattened, the playback would not be truly 
random :(

>    1) We need flat views

We need a flat playlist. Whether it's a view of something, is an 
implementation detail, and by the way, I'd argue *against* such an 
implementation.

>  - Some service libraries (MTP, Shoutcast, Upnp..., ) are hierarchy
>    centrics and are therefore trees.
>    2) we need tree views and therefore tree models

Again no. We need hierarchical storage. It does not need to be a view. We 
could have separate:
 - flat playlist, and
 - hierarchical media library.

No views are needed. And if we want to support lively updating media 
directories (e.g. Linux inotify), we need to reimplement directories in term 
of something other than the playlist, either the current service discoveries, 
or a future ML.

>  - Media libraries are going to be more and more important as number of
>    media grows.
>    Tags and searching are going to be more and more used than hierarchy
>    for those (see gmail, Win7 menu, spotlight...)
>    3) a local media library in a dB format will happen eventually, you
>       liking it or not (when do we merge jetru's work, btw?)
>    4) geeks and ordered people are probably going to like hierarchies

A database is good for a media library, especially for a persistent one.
It is not very good for a playlist - you don't want to run an SQL query to 
figure out what the next item is. This is too slow and inefficient.


> Do we need trees for current playlist? possibly not, but if you
> implement it for Services, how is it different now?

It wouldn't hurt to move SD away from the playlist. The current situation is 
legacy inherited from what used to be the "SAP extra interface".

> Could they be the same internally (trees) and flat would just be the
> view, when required?
> Here is the tricky question I think.

What's the point? It has just made our life more miserable this far.

> The views are going to be the Qt4 and Mac OS X interfaces (yeah, I don't
> care about other interfaces), but those views are not able sort nor to
> move correctly items in the current playlist.
> Sorting is done by the core (core must know what to play next),

Probably yes.

> and moving items can be tricky, (because of trees rendered in flat).

That's one of the reason why viewing a non-read-only tree as a list is 
fundamentally flawed.

> Ex, if you add 2 folders (a and b ) with 2 items (1, 2) in it, if the
> view is just a "flattener" of the core (as it was suggested by some
> people), then when you sort by artist(for ex.), how are you sure
> you don't end up with 2 sub-trees sorted and play (a2, a1, b1, b2) when
> the flattened view shows (a2, b1, a1, b2).

Yes, that's one problem I touched above. Again this is a fundamental flaw of 
the hierarchical playlist. And it cannot be fixed, even if we removed all 
"non-tree-capable" interfaces :(

> If we can figure out a correct way for the core to sort in flat mode,
> even if the rest in tree, that would be nice.

If the ML(+database) and the playlist are completely separate entities, non-
flat sorting is a non-issue.

> PS: before starting the work on breaking playlist (again!), please merge
> ECP-jetru's work on the SQL Media Library

The playlist and the media library are different things. If the patch touch 
the playlist core "much", I suspect there is something wrong with the patch 
(not that I know anything about it).

-- 
Rémi Denis-Courmont
http://www.remlab.net/