<p>Hi Remi,</p>
<p>First of all I would like to thank you for taking time to discuss this issue. I hope that we can reach a consensus and a solution to the given problem since I seem to have a fetish for playing nested entities (as shown by earlier screenshots).</p>
<p>Maybe I should seek help or that… <code>;-)</code></p>
<p>On 16/08/02 22:29, 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>Now if you have a filter downstream of the ZIP filter (that handles the 
fragment) and upstream of the final demuxer, it can reasonably expect that 
identical fragment-less URL leads to identical resource and representation 
thereof.</code></pre>
</blockquote>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>ArtCacheGetDirPath() is an existing embodiment. There may be others.</code></pre>
</blockquote>
<p>But the final demuxer should not care about where the currently processed resource is located; it shall only cares about the data it receives, and indirectly the data it spits out.</p>
<p>It is also worth-while noting that the fragment data is extracted from the MRL when an accessor is created, it is not part of the accessors psz_url, psz_location, or other relevant data-member (visible to a demuxer, if any).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>I don´t know if there is code that assumes (Lib)VLC never generates URLs with 
fragment in general. And I don´t know if there is code that relies on that 
assumption while prepending a hash and a chapter or title range.</code></pre>
</blockquote>
<p>If there is code that assumes that (lib)vlc does not generate URLs with fragments it is relying on a promise vlc has not guaranteed; does it not?</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>I don´t think we can determine that. The only question is whether you want to 
ignore that possibility and change the behaviour in incompatible ways 
(admittedly, it wouldn't be the first nor the last time we do that, cough 
cough).</code></pre>
</blockquote>
<p>I would like to be able to have a working solution to the problem, and as it seems we have exhausted other options the drawbacks associated with this implementation are relatively minor.</p>
<p>Dealing with a future standardization (regarding what we discussed earlier) is of course an issue, but deprecating a feature in favor of a new is not the first (and probably not the last) in terms of the codebase’s history.</p>