[vlc-devel] [RFC] Nth playlist rewrite

[Rafaël Carré]

On Sat, 2008-03-15 at 23:38 +0100, Pierre d'Herbemont wrote:
> 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.

I don't really understand here.

The way to view i can imagine a graphical representation.
The playlist object I imagine the C structures.
The way to play, I don't know O:

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

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

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

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

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

I'll see that with the admins when I'll have something to share ^^

-- 
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080315/a3cd8120/attachment.sig>