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

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 UTC