[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