- From: Yves Lafon <ylafon@w3.org>
- Date: Mon, 1 Dec 2008 05:23:01 -0500 (EST)
- To: Conrad Parker <conrad@metadecks.org>
- cc: Media Fragment <public-media-fragment@w3.org>
On Sat, 29 Nov 2008, Conrad Parker wrote:
>
> Hi,
>
> Regarding the method of retrieving media data in two parts over HTTP,
> I think the term "4-way handshake" is a bit of a misnomer. The word
> "handshake" implies protocol setup, whereas what we're really talking
> about is a two-part request, where the first typically retrieves a
> small but not insignificant amount of data (~10-100kB) which is
> particular to the subview being requested -- media headers, keyframes
> etc. As that data is necessary and immediately useful, I think it
> would be incorrect to say that this method adds any appreciable
> latency to the media request.
I wouldn't call it a two-part request, as it's two different requests,
completely unrelated (as seen form the server). The first request is to a
new resource with a non-video media type, and the second is a byte-range
request on another URI to retrieve part of the compressed video.
> Further, use of this method is optional, such that if the user agent
> does not specify to do so in the HTTP request headers then it simply
> receives all the data immediately as a normal GET request.
>
> Perhaps it would be more accurate to talk about an (optional)
> byte-range redirection than a handshake.
>
> cheers,
>
> Conrad.
>
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Monday, 1 December 2008 10:23:10 UTC