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

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] ...

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 08:10:39 UTC