- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 16 Jun 2011 14:26:55 +0200
- To: public-media-fragment@w3.org
On Thu, 16 Jun 2011 13:50:53 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Thu, Jun 16, 2011 at 6:33 PM, Philip Jägenstedt <philipj@opera.com> > wrote: >> On Wed, 15 Jun 2011 23:40:00 +0200, Jack Jansen <Jack.Jansen@cwi.nl> >> wrote: >> >>> I've been thinking a bit about whether or not we should split the >>> section >>> on HTTP implementation >> >> I would support splitting out or removing the HTTP section, on the basis >> that we do not intend to implement it. When/if we implement MF it will >> be >> client-side only, relying only on byte range requests. > > But that's what 5.2.1 describes, so why remove it? > > Also, the spec is not just for browsers - it is for all sw that > intends to support MF URIs. > > Why remove things now just before the spec gets into the hands of > implementers? It's just a CR and not a PR. OK, to clarify: I support dropping section 5.2.2 Server mapped byte ranges because of the reasons stated above. I also support dropping section 5.2.1 UA mapped byte ranges, because: 1. What it describes is mostly not specific to MF, it's something that generally applies to byte range requests. 2. Dealing with byte range requests and caching for <video> is quite messy, a high-level description like this doesn't help me as an implementor. The HTML spec says nothing about how to seek to a particular time offset using HTTP, and I don't think MF needs to either. In short, I support removing it because it's not useful to me, and probably not to any browser implementor. If other implementors step forward and say that they find it valuable, then I will also not object to keeping it. -- Philip Jägenstedt Core Developer Opera Software
Received on Thursday, 16 June 2011 12:27:09 UTC