W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

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

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 20 Apr 2009 04:09:34 +0900
Message-ID: <dba6c0830904191209u4d454954l9820abd8fe708acb@mail.gmail.com>
To: Michael Hausenblas <michael.hausenblas@deri.org>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Media Fragment <public-media-fragment@w3.org>
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.

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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Received on Sunday, 19 April 2009 19:10:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:33 GMT