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

Re: Backwards compatibility and the use cases and requirements draft

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 17 Dec 2008 21:04:30 +1100
Message-ID: <2c0e02830812170204n417f8a9did803dc1522407e04@mail.gmail.com>
To: "Yves Lafon" <ylafon@w3.org>
Cc: "Geoffrey Sneddon" <foolistbar@googlemail.com>, "Media Fragment" <public-media-fragment@w3.org>

On Wed, Dec 17, 2008 at 8:24 PM, Yves Lafon <ylafon@w3.org> wrote:
> 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.

I think that's what I said (i.e. it's dealt with client-side). Except,
it was my assumption that the server will 404 a media fragment request
where it doesn't understand a few extra message headers. That's
probably wrong and the server would by default reply with the full
resource if it cannot resolve the fragment (at least in the HTTP case
- not sure what happens in the RTP/RTSP case).

So, I have adapted the statement on the wiki. :)

Cheers,
Silvia.
Received on Wednesday, 17 December 2008 10:05:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:31 GMT