Re: media fragment URI use on web pages

On Wed, 17 Nov 2010 10:50:38 +0100, Raphaël Troncy  
<raphael.troncy@eurecom.fr> wrote:

>> For example, we can't
>> send additional HTTP headers based on the presence of #t=1 on the first
>> request, unless put into the URL/URI/IRI spec itself, which I doubt will
>> happen.
>
> Why not? This is exactly what we have discussed at the F2F meeting, read  
> http://www.w3.org/2010/11/02-mediafrag-minutes.html#item05. This has  
> lead to "ACTION-197: Raphaël to also add in the intro of Section 5 a  
> paragraph explaining the optimistic processing of fragments (using  
> ranges in seconds)". This is a proposal, but I think worth to  
> investigate.

The semantics of the fragment identifier is defined by each MIME type  
registration. Before we know the type, we can't assume anything.  
Therefore, the only possibility is if the URL/URI/IRI spec itself states  
that #t=1 has some semantics for *all* types and that this should cause  
headers Foo and Bar to be sent. However, I truly doubt we'll see  
media-specific things like this put into URL/URI/IRI, it's seems like a  
gigantic layering violation.

>> Again, the issue Silvia brought up was specifically if we could use MF
>> on web pages, i.e. with HTML. http://example.com/video.webm#t=1 should
>> just work, whether in <video src> or in the address bar.
>
> Assume that the optimistic processing of fragments is implemented by  
> browsers, just for the time dimension (95% of the use cases) using range  
> requests expressed in seconds, then, before knowing what the resource  
> would be, the browser has issued a range request:
>    - if this is a video, then, great it works.
>    - if this is a html page, scroll to the section id

So far so good.

>    - if this is a html page embedding a video (e.g. a Youtube page), and  
> that there is no section id "t=...", then play the video from t
> Just a silly proposal.

This is the part that I don't see working. Changing the interpretation of  
the fragment component for HTML at all seems too risky. Making it  
dependent on the markup would complicate things further, you'd have to  
wait until the page has finished loading before doing anything.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 17 November 2010 10:06:33 UTC