W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Review of section 7

From: Yves Lafon <ylafon@w3.org>
Date: Sun, 12 Apr 2009 14:55:04 -0400 (EDT)
To: Conrad Parker <conrad@metadecks.org>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0904121449250.23968@ubzre.j3.bet>
On Mon, 13 Apr 2009, Conrad Parker wrote:

> 2009/4/13 Yves Lafon <ylafon@w3.org>:
>> On Sun, 12 Apr 2009, Silvia Pfeiffer wrote:
>>
>>> * we need to mention that the replies are not cachable for the full
>>> resource, but cache only the fragmented resource, which can result in
>>> n copies of some subset of the resource in caching web proxies. Since
>>> it is typically expected that a fragment request will be used
>>> repeatedly (e.g. a fragment URI being shared around), this is
>>> potentially acceptable. But we have no experimental data to confirm or
>>> deny that this may pose a challenge to caching web proxies.
>>
>> Why? it is the case only if the cache can't handle merging timed fragment,
>> which is the case of general purposes caches (they will handle only bytes),
>> but media procies might be able to do so. Once again, it is not sure that
>> they will do that as requesting the whole resource and serve fragments from
>> the cache might be more efficient for such caches anyway :)
>
> HTTP/1.1 byte-range caching is a format-agnostic method, and already
> specified in an established standard. This WG has already determined
> that format-specific media proxy caching is not necessary for at least
> Ogg and MP4. If it is necessary for any other formats, we need to
> specify in detail what the format developers need to implement.

Oh, did I miss that byte range was in rfc2616 and httpbis drafts?
Can you point me to the decision saying that format-specific caches were 
not wanted?
The merging algorithm depends on the format, and it is not this WG's task 
to specify the algorithm. It is up to implementers and format 
specifications.

>>>   Example:
>>>
>>>    GET http://example.com/fragf2f.mp4 HTTP/1.1
>>>    Accept: video/*
>>>    Range: seconds=12-21
>>>    X-Accept-Range-Redirect: bytes
>>
>> One thing that I wonder is what happen if the reply is with two Range:
>> header, one in bytes, one in seconds.
>
> What is the use-case for both HTTP request headers?

Do the mapping between seconds and bytes.

> I haven't yet seen a use for Range units other than bytes that does
> not cause complications :-)

You think that the use of byte unit is without complications? :)

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Sunday, 12 April 2009 18:55:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:33 GMT