<p>Hi Remi,</p>
<p>Thank you for your feedback!</p>
<p>On 16/08/01 19:16, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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. + *
 Oh gosh. No please.
 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.</code></pre>
</blockquote>
<p>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.</p>
<ul>
<li>In what way can they not be nested (as detailed in the documentation)?</li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<p>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).</p>
<p>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).</p>
<p>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.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<p>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.</p>
<p>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).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> tl;dr: don't extend the generic URL syntax in proprietary manners.</code></pre>
</blockquote>
<ul>
<li><p>Are you saying that the documentation should be changed, or do you think the whole implementation is moot? If yes;</p></li>
<li><p>what would you propose as an alternative?</p></li>
</ul>
<p>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.</p>