[vlc-devel] [PATCH 1/3] Introduce media source and media tree API

[Romain Vimont]

On Tue, Jun 19, 2018 at 08:59:23PM +0300, Rémi Denis-Courmont wrote:
> Le tiistaina 19. kesäkuuta 2018, 20.00.15 EEST Romain Vimont a écrit :
> > Add an API to manage "services discovery" out of the playlist.
> > 
> > A "media source provider", associated to the libvlc instance, allows to
> > retrieve media sources (each associated to a services discovery module).
> > 
> > Requesting a services discovery that is not open will automatically open
> > it. If several "clients" request the same media source (i.e. by
> > requesting the same name), they will receive the same (refcounted) media
> > source instance.
> > 
> > As soon as a media source is released by all its clients, the associated
> > services discovery is closed.
> > 
> > Each media source holds a media tree, independant of the playlist, used
> > to store the input items detected by the services discovery. Clients may
> > connect callbacks to the tree to be notified of changes.
> 
> I still don't see any valid reasons to reinvent input_item and 
> input_item_node.

(I use input_item_t as it is.)

Indeed, I could use input_item_node_t instead of media_node_t as media
tree nodes. I preferred a specific type which knows its parent (contrary
to input_item_node_t), but I could adapt the API and callbacks. Would it
be ok for you?

> And in any case, there are reasons why input_item is not tied to an object: 
> the item can outlive its maker (while one object per item would be too heavy).  

OK, I agree, media_tree_t should not be tied to an object.

The only reason why I added it was for logging (calling msg_Warn()
requires a vlc_object_t). How to log properly without a VLC object?

> So you cannot have media source tied to an object either. It's either going to 
> break immediately, or become an enormous mess and break sooner rather than 
> later.

However, a media source necessarily outlives its parent
(the media_source_provider_t, stored in p_owner), so it can be a
vlc object.

Nevertheless, this may be unnecessary: for now I don't even log using
that object, so I can remove it.