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

Re: video use-case

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 7 Oct 2008 03:10:37 -0400 (EDT)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Jack Jansen <Jack.Jansen@cwi.nl>, Yannick Prié <yannick.prie@liris.cnrs.fr>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0810070259350.15200@ubzre.j3.bet>

On Mon, 6 Oct 2008, Silvia Pfeiffer wrote:

> My understanding of the URI RFC (now at
> http://www.ietf.org/rfc/rfc3986.txt) is that a fragment is a secondary
> resource that is addressed through the primary resource. For something
> like http://www.example.com/text.html#id12345 the primary resource is
> a html page. Seeing as the URI RFC states that the fragment is not
> being communicated to the Web server, but only handled within the UA,
> this request will always mean that a Web server will return the full
> html page and the UA has to do something with the fragment.

But what prevent the client to issue a something like a range request, if 
it is easy to figure out a way to request the fragment you need?

> So, the only way in which I can see this working is that the UA
> displays full-context for a screen display (as is customary), but when
> dealing with braille it strips out only the relevant part. Is that how
> it works?
>
> I'm asking this because with media we cannot work in this way, since
> we may not want the full video to download to the UA in order to apply
> the fragment offset. This is the reason why we were not able to use
> the "#" URI fragment for specifying temporal URIs, but had to use the
> "?" URI query mechanism.

# can work, but the UA has to be aware it is dealing with video and a 
fragment inside this video, in that case it can optimize its requests to 
the server.

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

         ~~Yves
Received on Tuesday, 7 October 2008 07:11:13 GMT

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