Re: Use cases and requirements for Media Fragments: Chapter 8

2009/4/8 Yves Lafon <ylafon@w3.org>:
> On Tue, 7 Apr 2009, Raphaël Troncy wrote:
>
>> Dear all,
>>
>> I have added the chapter 8 in the main document, see
>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#retrieving-fragment
>>
>> In particular,  I have drawn two graphics that hopefully will clarify
>> everything. I'm more than happy to receive any feedback on this section. Any
>> taker?
>
> In the 4 way handshake, the first request is not using Range requests.
> (and if it did, the first response would have been 206).
>
> What could be done is...
>
> Using conneg (but it would be quite ugly).
>
> GET http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Accept: application/range-conversion-uri;q=1, video/*;q=0.5
>
> ->
> 307 Temporary Redirect
> Location:
> http://www.w3.org/2008/WebVideo/resolver/range-converter?video=2342fedca
>
> (but even there we need an API to know how to call the resolver).
>
> or...
> HEAD /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
>
> HTTP/1.1 200 OK
> Link: <http://www.example.org/my-range-resolver>;
> rel="http://www.w3.org/2008/WebVideo/range-resolver"
> Content-Type: video/whatever
> Content-Length: 12039012930
>
> (meta information of the whole video, without retrieving it)
>
> But you still need to know how to call the resolver (that info might be
> retrieved from the rel URI from the Link header)
>
>
> In any cases, the examples are a bit wrong, as only the "path query" part of
> the URI is in the GET .. HTTP/1.1 line.

Hi,

I've been thinking about generalizing this mechanism a bit recently to
allow caching of non-header data. Here's some notes towards that:

http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html

As for terminology, I really don't think the term "handshake" is
appropriate; especially when all that's really happening is that the
data retrieval is getting split across multiple HTTP requests.
Handshake seems to imply that just negotiation is going on, and that
this is delaying the actual data retrieval -- which isn't the case
here.

cheers,

Conrad.

Received on Tuesday, 7 April 2009 16:53:48 UTC