Re: updated server-parsed fragment wiki page

On Sat, Sep 19, 2009 at 4:58 PM, Conrad Parker <conrad@metadecks.org> wrote:
> 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.

So, if a current cache receives a range request that includes both,
byte ranges and a track request, it will not be able to resolve that?

What happens in the case of byte ranges and time ranges?

Cheers,
Silvia.

Received on Wednesday, 23 September 2009 09:53:26 UTC