[vlc-devel] [RFC] Moving services discovery out of the playlist

[Romain Vimont]

On Sun, Jun 10, 2018 at 06:52:11PM +0300, Rémi Denis-Courmont wrote:
> Le sunnuntaina 10. kesäkuuta 2018, 18.45.34 EEST Romain Vimont a écrit :
> > On Sun, Jun 10, 2018 at 06:08:12PM +0300, Rémi Denis-Courmont wrote:
> > > Le sunnuntaina 10. kesäkuuta 2018, 17.14.43 EEST Romain Vimont a écrit :
> > > > AFAIU, this is what happens at the playlist level currently (as a
> > > > consequence, in the UI, items provided by the SD and by preparsing
> > > > appear in a single tree).
> > > 
> > > No. The SD subtrees are currently expressly marked read-only in the
> > > playlist mapping. The SD adds and removes items via SD callbacks or input
> > > item node callbacks.
> > 
> > IIUC, this is what happens here.
> > 
> > The SD adds and removes items via SD callbacks:
> > 
> > <https://github.com/rom1v/vlc/blob/sd/src/media_browser/media_browser.c#L61>
> 
> Perhaps, but the document submitted for review does not separate write access 
> from read access to the tree in any way, implying that it's free for all.

That's true. I considered the "media tree" a general structure that
could in theory be used at different places, the caller would be
responsible to know if they can write to it (and for SD stuff, they
could not).

But for now, it's used only there, so I will make the write functions
"private".

About locks however (still in theory), I think the client should be able
to read/iterate over the tree if they want (this requires a lock, so
that nodes are not added/removed concurrently by SD/prefetch).

In practice, we will probably only react to media tree callbacks, but
it seems to me that it still makes sense to expose locks for this
purpose. What do you think?