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

On Mon, 20 Apr 2009, Conrad Parker wrote:

> 2009/4/19 Michael Hausenblas <michael.hausenblas@deri.org>:
>>
>> Silvia,
>>
>>> We never really captured the decision that was made for choosing "#"
>>> as the fragment identifying mechanism over "?".
>>
>> AFAIK, we did not yet agree officially (that is, in the sense of
>> 'RESOLUTION: yadayadayada ...') on this topic.
>>
>> I totally agree we should ASAP and describe it.
>>
>> Please note as well that precisely due to that reason (lack of decision
>> recording) I have raised ISSUE-8 [1] ...
>
> We agreed (at the Barcelona F2F) to specify mechanisms for handling
> both # and ? for media fragment URIs. Once the # syntax is translated
> into a request header form that can be server-parsed, the rest of the
> HTTP mechanisms (such as byte or time range handling) should be the
> same.

Well, for '?' the mechanism is simple, it's a regular request on a URI and 
you should retrieve the whole document, no ranges are needed here.
The only thing that we could add is a Link: header pointing to the 
resource containing the one being served.

>
> Conrad.
>
>>
>> Cheers,
>>      Michael
>>
>> [1] http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/8
>>
>> --
>> Dr. Michael Hausenblas
>> DERI - Digital Enterprise Research Institute
>> National University of Ireland, Lower Dangan,
>> Galway, Ireland, Europe
>> Tel. +353 91 495730
>> http://sw-app.org/about.html
>> http://webofdata.wordpress.com/
>>
>>
>>> From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>>> Date: Sun, 19 Apr 2009 16:09:06 +1000
>>> To: Davy Van Deursen <davy.vandeursen@ugent.be>
>>> Cc: Raphaël Troncy <Raphael.Troncy@cwi.nl>, Media Fragment
>>> <public-media-fragment@w3.org>
>>> Subject: Re: Description of the 2-ways and the 4-ways handshake
>>> Resent-From: Media Fragment <public-media-fragment@w3.org>
>>> Resent-Date: Sun, 19 Apr 2009 06:09:59 +0000
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Monday, 20 April 2009 07:18:42 UTC