[vlc-devel] [PATCH 06/11] playlist/directory: attach slaves to input items

[Thomas Guillem]

On Thu, Apr 7, 2016, at 11:32, Benjamin Adolphi wrote:
> I think it makes a lot of sense the way pf_readdir currently works. It
> just makes it harder for attaching slaves since we don't have all
> items available. But when we add the slave attaching to an access
> module, we could change the internal implementation of the pf_readdir
> function to not internally retrieve only one item at a time but all
> items on the first call and then cache them so subsequent calls don't
> have to read all items again. I have seen that the dsm module does
> this, but other modules for example nfs, sftp and ftp only retrieve
> one item at a time from the underlying protocol implementation, which
> in some cases might reduce network overhead. The question is: Would it
> be ok to change this or is it not acceptable because of potential
> network overhead?

There won't be any network overhead. In both case, all items are fetched
from the access.
For information, we'll need to (partially) revert this commit
http://git.videolan.org/?p=vlc.git;a=commit;h=88ffe1587824c27f35705ee28e607f80ca335b46


> 
> On Thu, Apr 7, 2016 at 10:15 AM, Thomas Guillem <thomas at gllm.fr> wrote:
> >
> >
> > On Thu, Apr 7, 2016, at 09:58, Benjamin Adolphi wrote:
> >> So we could do the attaching of slaves to input items in the access
> >> plugin implementations instead of the directory demuxer. That way, the
> >> access plugin (which knows best) can decide how subtitles are matched
> >> and we can add support for different protocols one by one. Is that an
> >> acceptable solution?
> >>
> >> The only thing I am not so sure about is how this would be implemented
> >> best. The way the pf_readdir functions are implemented is that they
> >> return one input item per call. Most implementations never have the
> >> whole list of all items in a directory available. I guess we could
> >> retrieve the whole list on the first call already and cache them (the
> >> way the dsm plugin does for example). But this would potentially cause
> >> more network overhead than before because the caller might not intend
> >> to list all the content of a directory. Would that be ok or does
> >> someone have a better idea?
> >
> > Initially, pf_readdir was returning a list of items. But I changed it
> > back to the current behaviour in order to factor some code and to be
> > more consistent with readdir functions (readdir functions usually return
> > one item per call, and return NULL to signal an EOF).
> >
> > I'm not sure if it's a good idea to change the pf_readdir behaviour
> > again.
> >
> >>
> >> On Wed, Apr 6, 2016 at 11:05 AM, Rémi Denis-Courmont <remi at remlab.net>
> >> wrote:
> >> > Le 2016-04-05 23:09, Benjamin Adolphi a écrit :
> >> >>
> >> >> Ok, so I realize that it is complicated or probably even impossible to
> >> >> compare URLs in a scheme-independent manner. So what about limiting
> >> >> scope? We don't really want to compare any kind of URL against any
> >> >> other kind of URL. What we want to do is compare filenames and file
> >> >> extensions. So we can of course not do this with URLs that do not have
> >> >> a path. So let's limit which schemes we support to schemes that
> >> >> actually have a path (and that VLC actually supports).
> >> >
> >> >
> >> > Right now, all directory access plugins provide traditional filesystems
> >> > semantics. It won't stay that way for long. A lot of assumptions that hold
> >> > true now will soon no longer hold true.
> >> >
> >> > How do you even know that the URL scheme is conductive to comparison and
> >> > searching for subtitle files? How will be deal with HTTP(S), which can wrap
> >> > regular filesystems as well as very different beasts?
> >> >
> >> > I think handling the matching correctly in the directory access or the core
> >> > is essentially impossible. Only the access plugin instance has enough
> >> > specific knowledge.
> >> >
> >> >
> >> > --
> >> > Rémi Denis-Courmont
> >> > http://www.remlab.net/
> >> > _______________________________________________
> >> > vlc-devel mailing list
> >> > To unsubscribe or modify your subscription options:
> >> > https://mailman.videolan.org/listinfo/vlc-devel
> >> _______________________________________________
> >> vlc-devel mailing list
> >> To unsubscribe or modify your subscription options:
> >> https://mailman.videolan.org/listinfo/vlc-devel
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel