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

[Rémi Denis-Courmont]

Le tiistaina 2. elokuuta 2016, 20.00.18 EEST Filip Roséen a écrit :
> > > I'm quite sure we said that we should use the fragments to define the
> > > subfiles inside the archive. And that we could recurse if we encode the
> > > "#" in it, to have a .zip in a .rar in an iso on a smb share.
> > 
> > Without a standard on fragment within archives, it might be
> > problematic in the future. It is also wrong in some ways:
> > - Because it changes the representation of the resource, it should be
> > passed to the authority and caches. Fragments are not passed that way.
> > That is hopefully inconsequential in VLC now, though I do not know for
> > sure.
> 
> As the relevant RFCs describe, the purpose of a fragment is to not bother
> the authority with this kind of information; it is to be dealt with in the
> user-agent.

>   - What do you mean when you say that it *"changes the representation"*,

I mean exactly that it changes the representation in the HTTP sense. In fact, 
it´s a different resource altogether. We could argue at length on the fuzzy 
distinction between the representation of a resource and the performance of 
the resource on the user agent. But when it comes to byte streams, it´s clear 
that changing the byte stream is changing the representation, not the user-
agent processing.

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.

ArtCacheGetDirPath() is an existing embodiment. There may be others.

>     and;
>   - how does this relate to accessing a *secondary-resource* (which is what
>     fragments are about)?
> 
> Yes, the future of such standardization is still untold; but waiting for a
> standardization when it is a problem we have to deal with at the current
> time is in my opinion unwise.
> 
> When, if ever, a standardization comes through that should of course be
> favored.. but at the current time there is no standardization, and what we
> are doing is not in violation of any standardization currently in practice
> (as far as I know).
> 
> > - It changes the way the "final" downstream fragment is coded. We can
> > no longer simply append a hash sign and the existing title/chapter
> > syntax to the location.
> 
> I really hope we do not have such usage within the code-base given that it
> is a pretty much direct way to mess things up in one way or another.

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.

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).

-- 
Rémi Denis-Courmont
http://www.remlab.net/