RE: Description of the 2-ways and the 4-ways handshake

Hi Raphaël,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-
>fragment-request@w3.org] On Behalf Of Raphaël Troncy
>Sent: Thursday, March 05, 2009 2:45 PM
>To: Media Fragment
>Subject: Description of the 2-ways and the 4-ways handshake
>
>Dear all,
>
>I have made my stab on the description of the 2-ways and the 4-ways
>handshake proposal. See
>http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation
>
>All comments welcome! I asked some questions (regarding the first HTTP
>response code in the 4-ways handshake). The pro/cons need also to be
>completed. In particular, I'm not sure about the cachability of the
>resource in both cases?

Regarding the pro/cons, you mention 'We create a custom Range unit' as a
con. However, IMO this does not depend on whether we use 2-way or 4-way, but
whether the # or ? character is used. If the # character is used, then we
need a way to tell the server about the fragment (for instance by creating
custom range units in case of HTTP). Hence, what do you think of the
following pro/con list:

* 4-way handshake:
	+ current web proxies are able to cache media fragments
	- two roundtrips

* 2-way handshake
	+ one roundtrip
	- specialized 'media'-caches are necessary to cache media fragments

Further, you mention that the first HTTP response (in 4-way handshake)
includes "all additional data that cannot be cached but is required by the
UA to receive a fully functional media resource". Shouldn't we rephrase this
to "header data, occurring at the beginning of the media resource, that
cannot be cached but is required by the UA to receive a fully functional
media resource"? Otherwise, things become very complicated for the UA. Note
that you could also mention this restriction as a con for the 4-way
handshake (and/or a pro for the 2-way handshake). For instance, extracting a
spatial region from a Motion JPEG2000 would not work with the 4-way
handshake, but would work with the 2-way handshake (see also the table at
[1]). However, until now, I can only refer to Motion JPEG2000 to illustrate
this difference in 2- and 4-way handshake; all other media formats are
characterized by a fixed non-cacheable header occurring at the beginning of
the media stream (and are thus compatible with the 4-way handshake
approach). 

Best regards,

Davy


[1]
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Fragment_Caches#Media_fo
rmat_classification 


-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems 
Multimedia Lab
URL: http://multimedialab.elis.ugent.be

Received on Thursday, 19 March 2009 13:10:40 UTC