W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2008

Re: Backwards compatibility and the use cases and requirements draft

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 17 Dec 2008 04:24:23 -0500 (EST)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Geoffrey Sneddon <foolistbar@googlemail.com>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0812170422260.23529@ubzre.j3.bet>

On Wed, 17 Dec 2008, Silvia Pfeiffer wrote:

> Ah yes, that's just the wiki page, but we will indeed put a version of
> this into the use cases and requirements section of the specification.
> I've added a blurb at the end of the "side conditions" section on that
> wiki page about fallback solutions. After having thought about it a
> bit more, it is probably not a good idea to do the full media resource
> download by default. For example, think about a media fragment URI to
> an offset of 15 hours into a 20 hour long video for a 2 min long
> fragment. Think about such a request on a mobile phone. With almost
> certainty, you do not want your phone to just go off and download the
> full resource instead of the 2 min excerpt.
> So, I think the user agent should inform the user of the failed
> fragment URI and give the user the option to get the full resource,
> but not do it by default.

No, it would be against the "ignore what you don't know" rule. The client 
will see an incoming file with a _big_ Content-Length, that let the client 
decide to drop the connection to abort the transaction, but it has to be a 
client-side behaviour, not a server-side one.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Wednesday, 17 December 2008 09:24:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC