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

Going back over past discussions, I just stumbled across this.

We never really captured the decision that was made for choosing "#"
as the fragment identifying mechanism over "?". I think we will need a
brief discussion about the advantages and disadvantages of these two
approaches in the WD and an explanation of when to choose what. This
needs to be more than the one sentence written in 6.1.

Cheers,
Silvia.


2009/3/20 Davy Van Deursen <davy.vandeursen@ugent.be>:
> 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 Sunday, 19 April 2009 06:09:58 UTC