[vlc-devel] [PATCH 06/11] playlist/directory: attach slaves to input items
Steve Lhomme
robux4 at gmail.com
Wed Apr 6 08:30:01 CEST 2016
On Tue, Apr 5, 2016 at 11:09 PM, Benjamin Adolphi <b.adolphi at gmail.com> wrote:
> 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).
>
> In addition, if we are afraid of comparing URLs with different schemes
> (I am not sure if this is potentially problematic), we can also limit
> the comparison to only compare URLs with the same scheme. Since we are
> adding the slaves from the directory demuxer, the slaves and the input
> item will have have URLs with the same scheme anyways.
I'd like to know when string comparison of 2 URIs can produce false
positive. How can "scheme://host:port/path" point to different data
than "scheme://host:port/path" ? Or is it because of the possible
queries after these URL parts ? Again if the query parameters are the
same IMO we should consider it's the same data. Or it could be a
possible parameter in a URI comparator in VLC. For example when
looking for subtitles in a local dir either it's file based and there
won't be queries or it's HTTP (like) and you probably don't want files
that may be incorrect.
> On Tue, Apr 5, 2016 at 7:49 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
>> Le 2016-04-05 18:53, Thomas Guillem a écrit :
>>>
>>> On Tue, Apr 5, 2016, at 10:17, Rémi Denis-Courmont wrote:
>>>>
>>>> Le 2016-04-05 08:22, Steve Lhomme a écrit :
>>>> > What is the issue here ? Do we want to avoid false positive slaves or
>>>> > false negative salves ? I'd assume we want to avoid false positive
>>>> > and
>>>> > a basic string comparison avoids that.
>>>>
>>>> strcmp() on URIs is subject to both false positives and false
>>>> negatives.
>>>
>>>
>>> What about doing a comparaison of p_item->psz_name (only if it has an
>>> extension) ?
>>
>>
>> Uh? psz_name is a human-readable meaningless string. AFAIK, it is routinely
>> modified while preparsing, so relying on it is insane.
>>
>>
>>
>> --
>> 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
More information about the vlc-devel
mailing list