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

[Thomas Guillem]

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