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

Re: ACTION-112 follow-up: Conrad's vs current's proposal for Media Fragment Processing

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 9 Dec 2009 05:13:14 -0500 (EST)
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
cc: Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.0912090509190.21439@wnl.j3.bet>
On Tue, 8 Dec 2009, RaphaŽl Troncy wrote:

>> The mechanism I proposed (a separate Fragment request/Content-Fragment
>> response header pair) would work and is cacheable on the current web.
>> 
>> The mechanism in the current spec is not cacheable at all until the
>> entire web changes to support an as-yet-undefined caching mechanism.
>
> I disagree. The mechanism described in the current spec as the 4-ways 
> handshake (aka 2 roundtrips) that also introduce 2 new headers 
> (Range-Redirect and Accept-Range-Redirect) have exactly the same properties 
> than your mechanism and can be cached since in the second roundtrip, the 
> request for a track is converted into a byte-range request.

Well, if a cache, not knowing how to _combine_ time ranges wants to store 
'as is' and serve it back, based on matching headers, it is... cached and 
perfectly valid. There is no 'an as-yet-undefined caching mechanism' to be 
defined.
What needs defining may be how to combine time ranges entries within a 
cache, but that's not related _at all_ to caching mechanism, which is 
crystal clear and defined in rfc2616.

>> Basically I'm viewing things like "track=audio" the same way that
>> Language representations are handled. It works and it doesn't
>> interfere with caching.
>
> I like this argument.
Yes, track=audio is not really a fragment, doing conneg on content is more 
in order, in that case sending back a CL with a "?"-grade URI would be in 
order.

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

         ~~Yves
Received on Wednesday, 9 December 2009 10:13:17 GMT

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