[vlc-devel] playlist: flat / tree separation

[Jakob Leben]

On Sat, Aug 22, 2009 at 5:03 PM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

> You are still answering in a technical way to a "use case" mail.
>

OK, sorry for misunderstanding. I must admit though that I find your
terminology misleading. I thought you were speaking about models and views
as in MVC. Or in other words, about something like the current
media_list/media_list_view pair.

In the end, yes, I agree, we will need to present to the user both lists and
trees. But that is very obvious, I would like to speak about implementation.

About implementation: the purpose of my first mail under this topic was
simply to check whether all of you agree that we don't need the same data
being stored both as a list and as a tree and trying to synchronize those
two. I deduct we all agree on that. Is it so?

Moreover, I think we agree that it is absurd to ever have a flattened "view"
of a tree "model" (as in MVC and as in media_list / media_list_view)...

...and that we also agree that we don't need models and views (again: as in
MVC) in the core at all (because the core shall only supply models and gui
interfaces produce the views).

-----

 would like to also touch the following topic and check your opinion, even
though the answer may be too trivial:

1.I think all the media available to the user to play (be it the playlist,
the media library, the service discovery listings etc.) shall be finally
stored with the same data structure (just like it is now all stored with
playlist_item_t structures) - no matter were it comes from. Even SQL media
library shall be finally stored with that same data structure (though, as
Rémi pointer out, we should name that structure differently to not be
confused with the actual playlist).
The reason for this is encapsulation: So that we can have generic functions
operating on all of them, and so that we can have for example one and only
QAbstractItemModel implementation that can handle all of them.
This may be very trivial, but again, I just wanted to check your opinions.

2.This universal struct shall allow for tree structures (just what now
playlist_item_t does), as this means it automatically allows also for list
structures.

3.Now if we call entities like the playlist, the media library, a singular
service library's listing with a generic name "media item groups" then the
only essential difference between a list and a tree type media item group
shall be in a per-media-item-group flag ("this is a list / this is a tree")
according to which the generic media group handling functions can determine
whether tree structured data must be flattened before inserting it and if it
is possible to create nodes in that media group etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090822/a93bd5c7/attachment.html>