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

[Benjamin Adolphi]

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?

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