- From: Conrad Parker <conrad@metadecks.org>
- Date: Mon, 20 Apr 2009 04:09:34 +0900
- 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 UTC