- From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Date: Wed, 08 Apr 2009 00:34:44 +0200
- 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. Cheers. Raphaël -- 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