[vlc-devel] [RFC] Nth playlist rewrite

[Pierre d'Herbemont]

Quoting Rafaël Carré <funman at videolan.org>:

> On Sat, 2008-03-15 at 23:38 +0100, Pierre d'Herbemont wrote:
> > Quoting Rafaël Carré <funman at videolan.org>:
> > IMHO, we need to separate the way you *view* the playlist, the way you
> *play*
> > the playlist and the playlist object. That's basically what is done in
> libvlc
> > and it's again, I think, the right way to do this. Any other way cannot be
> as
> > elegant and modular.
>
> I don't really understand here.
>
> The way to view i can imagine a graphical representation.

Exactly. You can view a playlist, sorted by name, hierarchically, flat, etc.

> The playlist object I imagine the C structures.

That's the model object, where the data are actually. (Eg: a database table, or
a simple array)

> The way to play, I don't know O:

That's basically the task reponsible for playing a choosen playlist, using a
certain method. Shuffle, Random, Fade-In. It manipulates the input_thread_t
basically.

This is really close to the Model-Control-View abstraction, which helps to
separate modularize most problems, and solves common troubles.

Basically it means, you can have a playlist model object.

You can then see this object differently using multiple playlist view objects.
(1)

And you can play it using different playlist player objects. (2)

(1) solves the sorting, and the hierachical/flat problems.

(2) solves the vlm problem, and opens new ways to deal with how to play a
playlist.


> > > So I would like to ask the elders : what was this for ?
> > > - * It is envisioned that a third tree will appear: VLM, but it's not
> > > done yet
> > >
> > > Was it worth ? Is there some feature I fail to understand, like the
> > > ability to manage VLM through any GUI ?
> >
> > IMO, the idea was to be able to load a playlist file from VLM.
>
> I don't know VLM, so I can't comment.

(basically You can't feed VLM an m3u)

>
> > > If this is the case, and nobody is coming to do the work, I'll simply
> > > revert that branch, and statically link the inputs to the playlist, in
> > > order to remove the input_item_subitem_added() UGLY HACK added by
> > > pdherbemont (Pierre d'Herbemont) for the vlc-control API (carrying its
> > > own memory corruptions).
> >
> > You'll have to be *way* lot more specific here.
>
> When I'll have another crash with backtrace ..

I was asking about the "revert that branch, and statically link the inputs to
the playlist". Do you mean that you are just going to remove the effort to
separate playlist and input?

If so, it seems to me that this is wrong. The playlist is creeping enough
everywhere (Interaction is one more place btw.).

That is a nice way to make sure that there is no circular dependency between
playlist and input, given that from a conceptual point of view, the playlist
should be kept away from the input. The playlist should manipulates input, and
not the other way around.

> > Moreover, the input_item_subitem_added() is only an event handler for the
> > input_AddSubItem call. It can't work well with current playlist (hence the
> nasty
> > hack) but do work well with libvlc-control. So how do you plan to remove
> that
> > input_AddSubItem abstraction?
>
> By statically linking each input_item and playlist_item, i.e. associating
> them for life.

Don't you feel that playlist_item should have an input_item and not the other
way around?

I am really trying to understand what you want to do. The only way that I could
agree with you would be:
- Have each input_item to have a list of its subitems.
- Not to put any more playlist stuff in the input.

This way could work nicely, but I am a bit skeptical. It adds some overhead in
the input which could be kept in a separate object. (So that you can nicely put
that in a sqlite db for instance).

You'll have to note here that in libvlc_media_list, the unit is the
libvlc_media_descriptor (which is an input_item basically). And the
media_descriptor has a function that returns its subitems as a media_list. This
means that the media_descriptor acts as a subclass of the input_item. And where 
you propose to merge, libvlc proposes to subclass.

What does it allows to do to keep them linked?

> > > It MAY cause some (external, aka vlc-control) API changes, and afaik
> > > 0.9.0 is already bringing changes here, so I want to have this ready for
> > > the next release, hopefully with the help of pdherbemont
> >
> > The external API is fine. You can change the core if you like though, but I
> fail
> > to see why you would change the external API. (I do care about them, and
> you'll
> > have to show me why they are badly done.)
>
> I didn't read the external API yet, I just supposed it may be bound to
> some functions which would disappear.

hum. ok.

If you want my opinion on that. The new playlist code should basically have the
same interface (read, same way classes are splitted, media_list,
media_list_view, media_list_player) than the libvlc_media_list API. If you do
that you have my blessing.

Also, I do think that the media_list stuff needs some improvement (_player part
hasn't been finished, mostly due to input_thread_t issues), but is the good way
to go, and I do propose them as a playlist successor.

Thanks for your answer,

Pierre.