[vlc-devel] [RFC] Nth playlist rewrite

[Pierre d'Herbemont]

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

> This not finished state included : memory corruption due to the complex
> handling of 2 separate trees: one with nodes, and one without (also
> known as flat)
>
> The first thing I started here is removing the flat tree, and leave the
> work to display a flat playlist to other modules.
> I quickly noticed that I was reverting
> [ed0b72e3714ad87cb4e10b9a7239e19b9ef0724e] which reads "Merge back
> branch 0.8.6-playlist-vlm to trunk."

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.

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

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

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?

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

> The playlist internal API is quite complex, and some stuff (a.k.a
> preparsing and metadata fetching, such as album art) is badly
> implemented/splitted across input and playlist.

Agreed.

> Stay cool, I'll do that on my PRIVATE tree (which I'm ready to share
> with interested people) and will not merge it without your approval.

That's the right way to do that I think. (That would be nice to publish it on
git.v.o too).

Pierre.