<p>Hi Remi,</p>
<p>On 16/08/02 17:54, 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 2016-08-01 18:32, Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<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>
<pre><code>I do recall pointing out that the archive stream filter had already solved the problem,
at least for the most part, and without changes to the core. In other words, if you want
to embed stuff arbitrarily, you can define custom MRL schemes. IMO, it diverges from the
principles of the URL syntax a lot less than overloading the URL fragment.</code></pre>
</blockquote>
<p>The problem with using a custom MRL scheme is that it will be very painful to do something like what is being done in the following screenshots:</p>
<ul>
<li>http://atch.se/nested_archive_http.png</li>
</ul>
<p>In order to properly implement a solution that uses custom MRLs, the top-accessor responsible for opening an entity must open up another accessor in order to get the contents of the entity in which it is acting upon.</p>
<p>Looking at the implementation of <code>modules/access/archive/*</code> should give quite a clear image of what we would have to go through for every format that allows nested entities if we do not introduce something a long the lines of stream-fragments.</p>
<h3 id="a-note-about-stream-filters">A note about stream-filters</h3>
<p>If the accessor responsible for handling a custom MRL does not remember to append the appropriate stream-filters associated with the aquired resource it will lead to unexpected data to be read (not the same as if we went through a proper access->stream_filter->demux chain).</p>
<p>A naive solution to the problem would be for the accessor to call <code>vlc_stream_FilterNew</code> on the aquired resource, though;</p>
<ul>
<li>how does it know what stream-filter to append?</li>
</ul>
<p>tl;dr it cannot.</p>
<h3 id="an-elaborate-example">An elaborate example</h3>
<pre><code>http://localhost/foo.zip
 |
 '- bar.rar
   '- movie.avi
   '- movie.srt
 '- foo.mp3</code></pre>
<p>We would have a <code>zip-stream_filter</code> that generates MRLs for the entities inside it with a custom MRL so that the appropriate <code>zip-access</code> can handle the extraction of the relevant element:</p>
<ol style="list-style-type: decimal">
<li><code>zip://http://localhost/foo.zip!bar.rar</code></li>
<li><code>zip://http://localhost/foo.zip!foo.mp3</code></li>
</ol>
<p>When you then open-up entity <code>(1)</code>, a <em>stream-filter</em> that handles <code>.rar</code> would spit out the following (theoretical custom MRL).</p>
<ol style="list-style-type: decimal">
<li><code>rar://zip://http://localhost/foo.zip!bar.rar!movie.avi</code></li>
<li><code>rar://zip://http://localhost/foo.zip!bar.rar!movie.srt</code></li>
</ol>
<p>Then, in order to open entity <code>(1)</code> from the above, the accessor-chain would be like the below:</p>
<p>[ rar access ] -> [ stream_filter* ] -> [ demux ] : ’- [ zip access ] /* feeding/owned by rar access <em>/ : ’- [ http access ] /</em> feeding/owned by zip access */</p>
<p>Given what is proposed in the patch-batch in which this email is a reply, it would instead look like the below, allowing “inifinite” nesting of filters in a more straight-forward manner:</p>
<pre><code>[ http access ] -> [ zip stream_filter ] -> \ 
[ rar stream_filter ] -> [ stream_filters* ] -> [ demux ]</code></pre>