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

Re: Discovery and fallback for media segment addressing over HTTP

From: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Date: Wed, 08 Apr 2009 00:34:44 +0200
Message-ID: <49DBD504.1030507@cwi.nl>
To: Conrad Parker <conrad@metadecks.org>
CC: Media Fragment <public-media-fragment@w3.org>
Dear Conrad,

>> The main criticism you have for the fragment, is the lack of a fallback plan
>> if the server does not handle the fragment request. In other words, the
>> whole resource will be send over the networks. Yes, but I don't see that as
>> a major drawback, and we can be confident that the situation will naturally
>> improve as soon as more and more web servers will handle media fragments.
> Also the lack of fallback if clients don't support these steps. I
> think there is a good use case for user agents not supporting extra
> steps (eg. a mobile browser with no on-board cache) but there being an
> intermediate proxy at the ISP which does that translation and caching.

I would now revert back your argument :-)
* With the current approach, the UA just needs to encode the fragment 
into a suitable range request in the HTTP method. Something that can be 
reasonably achieve by a add-on in a web browser for example, and can be 
reasonably expected to be the default in the future web browsers. 
Nothing more is needed, and in particular the ability for the UA to be 
able to do any sort of recomposition of bytes and extra header to 
finally get a playable resource. As Yves pointed out, the caching is not 
necessarily something useful to have.
* With your proposed approach, the UA does much more processing so there 
is a risk to falls more often in the fallback plan.


RaphaŽl Troncy
CWI (Centre for Mathematics and Computer Science),
Science Park 123, 1098 XG Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/
Received on Tuesday, 7 April 2009 22:35:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC