Re: Discovery and fallback for media segment addressing over HTTP

Dear Conrad,

> there were some recent questions about discovery (how does a client
> find out whether an HTTP segment response mechanism is available) and
> fallback (what happens if either the client or server fails to
> understand the mechanism). I've put together some thoughts here:
> 
> http://blog.kfish.org/2009/04/discovery-and-fallback-for-media.html

Another interesting blog post :-) ... though I disagree sometimes with 
what you say:

You wrote: "I will make the case that the user-visible differences 
between the two syntaxes are immaterial, and that a more important 
distinction is that they induce different protocols.".

For me, protocol = HTTP and there is no difference in protocol between 
the fragment or the query parameter.

You wrote: "I will also claim that the use of the fragment syntax 
introduces unnecessary complexity in that it lacks a discovery mechanism 
and has no useful fallback to existing HTTP."

This needs to be counter-balance. I don't see the extra-complexity, but 
I do see the benefit: the fragment has a natural filiation with its 
parent resource. The query creates a *new* resource. How will you 
specify back this relationship between the newly created resource and 
the original resource the part comes from? I don't see the answer in 
your blog post.

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.

I then like your explanation of the solution we are designing within the 
group. Could we use this text in the WD?

Ultimately, you wrote:
   "* To clarify within the Media Fragments WG how queries can be used 
effectively, for both considered user scenarios."

The WG has plan for using the query parameter. It will mean that a new 
resource is created, extracted from an existing resource. We still need 
to specify how the link will be made.

   "* To consider how the byte-range redirection mechanism can be 
generalized for other segment specifiers, such as spatial regions."

As the ISSUE-5 [1] raised by Jack shows, we are likely to have 
transcoding for the spatial cropping.

Cheers.

   Raphaël

[1] http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5

-- 
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/

Received on Tuesday, 7 April 2009 21:18:36 UTC