[vlc-devel] [RFC] immediate removal of media list

[Pierre d'Herbemont]

2009/5/12 Rémi Denis-Courmont <remi at remlab.net>:
>
> On Tue, 12 May 2009 16:52:10 -0700, "Pierre d'Herbemont"
> <pdherbemont at free.fr> wrote:
>> Yet, I know that you especially dislike that API. Which is from what I
>> know the only sane interface possible. (Compared to the old
>> libvlc_playlist_* stuff).
>
> And? People understood playlist. Not even I understand the media list
> stuff. I couldn't even figure what the locking scheme was (well, actually I
> figured out it was broken)... what about normal LibVLC programmers?

Locking is a complex problem. I am sorry, but you need to explain
which part of the API is broken. Given that it is correctly layered,
having a part of the upper layer broken does not affect the other. I
strongly suspect you speaking about media_list_player stuff.

> Besides, the playlist should be managed directly by the application, not by
> libvlc.

Depends on wether you want to write VLC on top of libvlc. Which would
makes sense IMO.

> Then, we anyway need to keep the playlist API around so that VLC
> itself will work.

If I get you correctly, you meant playlist_t from playlist core.
Right. It's an API with its problem that we don't want to expose.

> And last, it is reproducing the exact same mistakes than the core playlist
> has. Namely it mixes up flat and tree view.

No it doesn't. There is nothing but media_list: it is a simple list of
media. A media can have a sublist.

Everything is correctly layered from this point of view.

The media_list_view stuff (That is what you are talking about) is
purely optional. This is the stuff that brings on flat/tree list
option. I entirely agree that this could be kept apart from libvlc.
That makes it *very* different from original API.

Reminder: Original playlist_t API is not correctly layered.
- The data and the function are not differentiated: You can't play one
set of media, in two different playing environment.
- The data structure and its presentation are not differentiated: You
maintain two set of data (tree and flat) in the same object, with
inextricable functions.
- The playlist_t is a one shot type. You can't manage two playlist_t
at the same time in the same instance.

> In the core, this made sense
> because we can have two interface at the same time, one using flat view,
> one using tree view. In LibVLC, there is no such problem.

There is. Why wouldn't libvlc client be able to open SD and playlist file?

>> Please make your points soon against it, as there is no use to keep a
>> creepy API around for 1.0, as we'll have to deprecate it. Anyway, we
>> should do an API review before 1.0.
>
> It is broken. It is complicated. It is mostly useless: nobody uses it,
> otherwise they'd have noticed how broken it was anyway).

Well, the only real argument here is that the media_list_player is
unfinished, then broken.

Being complicated is never a good point. Unless it is for most usage,
then it becomes overengineered. IMO, libvlc should allow one to
rewrite VLC. In that use case, the media_list_* is the nearly the
minimal subset that comes to mind.

> In real life, people simply re-implement their own much simpler playlist
> scheme on top of the media player.

Which is certainly a good thing.

Well, I suggest you to throw what is not working. I'll eventually
re-introduce it, fixed. But vlc has become boring for me :/

I am kind of happy with the new attention brought to libvlc though.

Remember that the ultimate goal of libvlc is not to produce an API for
third party developers. It is to produce a sane API that a vlc app
could link against. Such as every sane application tends to do.

Pierre.