[vlc-devel] [RFC] Nth playlist rewrite

[Rafaël Carré]

On Sun, 2008-03-16 at 00:59 +0100, Pierre d'Herbemont wrote:
> 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.
> 

Yeah ..

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

right.

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

Not exactly, I am going to remove the multiple trees at a first step.
About inputs, scroll down.

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

Yeah....

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

This is exactly the "other way around" which happens with "sub items".

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

Why would an input move from one playlist_item to another ?
An input should have its own playlist_item forever.

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

Does that mean having both a hierarchy in the playlist, and one in the
input ? Freaky.

Well, we could remove the hierarchy from the playlist Model (internal
structure) and only use input hierarchy.

That means:
	1/ Keep a hierarchy only for the top playlist, i.e.
		PLAYLIST
			- local
			- media library
			- services discovery 1
			- services discovery 2

And each of these nodes would have inputs:
directory/
	|-file 1 (linked to directory's input)
	\-file 2 (linked to directory's input)
audio-cd
	|-track1
	\-track2
stream1
stream2
youtube_http_url
	\-flv


In this theory we have 5 playlist_item:
directory, audio-cd, stream1, stream2, youtube_http_url

and 10 input_item, 5 of them are not associated to the playlist in any
way.

BUT that means that for the GUI to manage the playlist View, it has to
mess with input code.

So I don't see how we can remove the circular dependancy here.

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

I don't know OO vocabulary.

Do you mean :

struct
{
	input_item_t 	*p_item;
	int		i_subitems;
	input_item_t	**pp_subitems;
} media_descriptor;

?

> What does it allows to do to keep them linked?

Why would we need the input_item_t to move around playlist_items ?

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

I'll have a look at this code, I never really did.

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

The next step is to propose a design (a drawing/picture) of what
playlist should do, how it communicates with other parts of the code, to
clear out any misunderstanding.

> Thanks for your answer,
> 
> Pierre.
-- 
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/20080316/f722edd1/attachment.sig>