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/