# [vlc-devel] [PATCH 02/21] input/stream: stream-fragments: add initial documentation

Filip Roséen filip at atch.se
Mon Aug 1 18:32:14 CEST 2016

Hi Remi,

On 16/08/01 19:16, Rémi Denis-Courmont wrote:

>      Le dimanche 31 juillet 2016, 22:42:11 Filip Roséen a écrit :
>      + * \subsection fragments_introduction What are fragments?
>      + *
>      + * \em stream-fragments are very much like the fragment described in \link
>      + * https://tools.ietf.org/html/rfc3986#section-3.5 RFC3986/3.5
>      + * Fragment\endlink, though (has hinted by the plural form of "fragment")
>      VLC + * can handle a fragment within a fragment; meaning that one can refer
>      to a + * secondary resource (nested entity), within another secondary
>      resource. + *
>      URL fragments are URL fragments are URL fragments. They correspond to anchors
>      in HTML documents, and their closest equivalent in VLC are title, chapter or
>      start time. They intrinsically cannot be nested.

The nesting is from our point-of-view, the URL remains a valid one; given
the description for how nesting is taking place I'm not sure I am following
exactly what you are referring to.

- In what way can they not be nested (as detailed in the documentation)?

>      We have had enough troubles due to differing interpretation of URLs and MRLs in
>      different code paths. We should know better than to further complicate and
>      worsen the problem.

Exchanging URLs with MRLs and vice-versa is fine given that the data of the
anchor is still valid (given that the nesting is done in a manner that is
compliant with RFC3986).

We have cases where VLC converts an URL with fragment (RFC3986) and/or
query-parameters to one without, which in my opinion is wrong (since it is
not referring to the same entity anymore).

These set of patches simply strengthens the relationship between MRLs and
URLs by saying that we do support anchors, and will treat as what they are;
an anchor into a secondary-resource.

>      And lets not even get started on the many cases whereby
>      VLC exchanges URLs to or from another program/source, and all the hacks
>      necessary to deal with broken URLs.

I don't see how these set of patches worsens the situation, nor do I see how
the exchanging of URLs to/from external resources is any different then
what we currently have.

There are issues to be fixed in regards of MRL vs URL, but I fail to see
how this implementation makes those issues harder to implement (I would
argue that its the opposite).

>      tl;dr: don't extend the generic URL syntax in proprietary manners.

- Are you saying that the documentation should be changed, or do you think
the whole implementation is moot? If yes;

- what would you propose as an alternative?

These set of patches are a direct reply to what we discussed in Vienna
earlier this year (during the core sessions), and given my notes from that
meeting this scheme falls very well into what was discussed as a viable
solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160801/0d9429d4/attachment.html>