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

[Benjamin Adolphi]

Ok, maybe I misunderstood something. If we for example look at the
sftp access module, it previously was calling libssh2_sftp_readdir
until it returns an error (i.e. until there are no more items). Now,
it will only call libssh2_sftp_readdir until it gets the first valid
entry. Also the ftp implementation is not looping anymore. It just
calls vlc_tls_GetLine or net_Gets once.

On Thu, Apr 7, 2016 at 11:54 AM, Thomas Guillem <thomas at gllm.fr> wrote:
>
>
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel