- 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>
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