<p dir="ltr">Hello,</p>
<p dir="ltr">Le 1 août 2016 5:32 PM, Filip Roséen <filip@atch.se> a écrit :<br>
><br>
> Hi Remi,<br>
><br>
> Thank you for your feedback!<br>
><br>
> On 16/08/01 19:16, Rémi Denis-Courmont wrote:<br>
>><br>
>>  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.<br>
><br>
> 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.<br>
><br>
> In what way can they not be nested (as detailed in the documentation)?</p>
<p dir="ltr">I do not know any standardized use of URL fragment that allows nesting, and indeed it wouldn't make much sense. A fragment is essentially a starting point for performing the resource. That does not leave an opportunity for nesting in general. There may be some level of nesting, such as chapters inside titles, but I do not know any case, standardized or proprietary of nesting with arbitrary depth. The standard HTML anchors certainly do not allow nesting.</p>
<p dir="ltr">Also, the fragment is a hint of whence to start performance. It is not a modifier for the underlying resource. In particular, you can still scroll an HTML page backward from the original anchor.</p>
<p dir="ltr">If you need to handle the fragment in an access or stream filter, something is wrong with the design. Fragments are ostensibly a demux-level matter, and belongs either in demux/access_demux, or as common code on top of those in input thread.</p>
<p dir="ltr">>><br>
>>  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.<br>
><br>
> 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).<br>
><br>
> 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 dir="ltr">But that is one of the point: we already have enough problems in dealing with standard URLs and with our grand-fathered proprietary extensions (forced demux and title/chapter), that we should most certainly not add new ways to mess things.</p>
<p dir="ltr">><br>
> 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>
<p dir="ltr">We do not support anchors. Anchors are an HTML concept, and VLC does not handle them.</p>
<p dir="ltr">>><br>
>>  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.<br>
><br>
> 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 dir="ltr">Well, I do see it.</p>
<p dir="ltr">> 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>
<p dir="ltr">It adds a non-standard and unforeseen extension to the syntax. The rest is obvious.</p>
<p dir="ltr">>><br>
>>  tl;dr: don't extend the generic URL syntax in proprietary manners.<br>
><br>
> Are you saying that the documentation should be changed, or do you think the whole implementation is moot? If yes;<br>
><br>
> what would you propose as an alternative?<br>
><br>
> 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.<br></p>