Re: updated server-parsed fragment wiki page

2009/9/19 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> On Fri, Sep 18, 2009 at 7:37 PM, Conrad Parker <conrad@metadecks.org> wrote:
>> Hi,
>>
>> yesterday we were discussing about which HTTP request header to use to
>> request a specific track etc. I think we agreed that Range should only
>> be used for continuous indexes (that can have a duration/length/size),
>> such as time or xywh.
>
> I don't think the outcome of the discussion was conclusive, but we did
> indeed mention this as another option.
>
>> I'm suggesting to use something like Fragment for things like track=,
>> id=. I've updated this wiki page to include a line about how Fragment
>> should interact with time Range requests, and a link to relevant
>> examples:
>>
>> http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments
>
> After having read all that, I am wondering why we would need to invent
> a "Fragment" protocol parameter that does essentially the same as the
> "Range" protocol parameter? Is there a reason "Range" doesn't work for
> "track"? What is different between "Range:" and "Fragment:" other than
> leaving out the <total duration> part on the "Fragment:"?
>
> I sympathise with the idea, but I cannot justify it without having
> these questions answered.

Ranges and tracks are orthogonal concepts. A track gives you some kind
of semantic view across the whole file. A range is a way of addressing
the whole file, or of addressing a track view.

In terms of caching, you may be able to store and recombine ranges
from the same view. For this reason Fragment is declared in the Vary
header; this allows ranges of a track to be cached, even by an
intermediary that does not understand what the track is all about (ie.
just using generic Range mechanisms). This would not be possible if
both track and range were supplied in the same header.

Specifically, it ensures that our track etc. selection schemes do not
interfere with existing HTTP/1.1 caches that do byte range handling.
The same may apply to future intermediaries that support time range
caching.

Conrad.

Received on Saturday, 19 September 2009 06:59:30 UTC