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

Romain Vimont rom1v at videolabs.io
Sun Jun 10 16:14:43 CEST 2018


On Sun, Jun 10, 2018 at 04:56:08PM +0300, Rémi Denis-Courmont wrote:
> Le sunnuntaina 10. kesäkuuta 2018, 16.42.03 EEST Romain Vimont a écrit :
> > On Sun, Jun 10, 2018 at 04:03:43PM +0300, Rémi Denis-Courmont wrote:
> > > Le sunnuntaina 10. kesäkuuta 2018, 15.38.17 EEST Romain Vimont a écrit :
> > > > On Fri, Jun 08, 2018 at 07:43:11PM +0300, Rémi Denis-Courmont wrote:
> > > > > Le perjantaina 8. kesäkuuta 2018, 18.05.58 EEST Romain Vimont a écrit
> > > > > :
> > > > > 
> > > > > And it makes zero sense to allow users to modify or lock the SD tree.
> > > > > An
> > > > > SD
> > > > > maintains its tree. Nobody else can modify it, and nobody else can
> > > > > decide
> > > > > when it gets modified.
> > > > 
> > > > In my proposal, the media tree is modified both by the SD (when it
> > > > detects new items) and by the browsing/preparsing (from different
> > > > threads).
> > > 
> > > You CANNOT change the media tree of an SD.
> > 
> > Why CANNOT?
> 
> Because you cannot reverse causality.
> SD add/remove items as a consequence of services becoming (un)available.

IMO that's the behavior we want. For example, some SD detects a server.
I browse its "directories", this adds nodes to the tree. Then the server
disconnects, this removes the server node and its children (including
the directories I browsed).

> You cannot just add an item into an SD-maintained tree.

I don't consider the media tree associated to a service discovery
"SD-maintained". Rather, the SD triggers some events that lead to
"populate" a tree.

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). In my proposal it happens at the "media
browser"/"media source manager" level instead.


More information about the vlc-devel mailing list