On Thu, 20 Jan 2011 01:14:12 +0100, Glenn Maynard <gl...@zewt.org> wrote:
On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt
<phil...@opera.com>wrote:
If the available bandwidth exceeds the bandwidth of the resource, some
kind
of throttling must eventually be used. There are mainly 2 options for
doing
this:
1. Throttle at the TCP level by not reading data from the socket (not at
all to suspend, or at a controlled rate to buffer ahead)
2. Use HTTP byte ranges, making many smaller requests with any kind of
throttling at the TCP level
You're talking about Opera's implementation and not in spec, right?
Yes, I'm just sharing my reasoning and conclusions.
This is
something UA's should have a lot of freedom with, and I assume this
low-level detail about how to use HTTP is out of scope for the HTML spec.
While I hope other implementors will take a similar approach (wildly
different behavior between browsers would like result in worse
interoperability), the spec shouldn't talk about HTTP or TCP, at least not
normatively.
(Since there is some overhead with each HTTP request, one must make sure
that they are not unreasonably small.)
When HTTP byte ranges are used to achieve bandwidth management, it's
hard
to talk about a single downloadBufferTarget that is the number of
seconds
buffered ahead. Rather, there might be an upper and lower limit within
which
the browser tries to stay, so that each request can be of a reasonable
size.
Neither an author-provided minumum or maximum value can be followed
particularly closely, but could possibly be taken as a hint of some
sort.
Does it actually make sense to specify the read-ahead size, or should it
simply be a flag (eg. "unlimited", "small buffer" and "don't care")? Is
there really a case for setting the actual read-ahead value directly?
In a
sense, that seems akin to allowing web pages to control the TCP buffer
sizes
used by the client's browser--it's lower level than people usually care
about.
In particular, I'm thinking that most of the time all people care about
is
"read ahead a little" vs. "read ahead a lot", and publishers shouldn't
need
to figure out the right buffer size to use for the former (and very
likely
getting it wrong).
I'm inclined to agree, and we already have a way to say "a little"
(preload=none/metadata) and "a lot" (preload=auto).
However, it'd be great if all implementors could agree on the same
interpretation of states. Specifically, this isn't required by the spec
but would still be helpful to have consistency in:
* effective state can only increase to higher states, never go from e.g.
metadata to none (it makes no sense)
* there is a state - invoked - between metadata and auto for when the
video is playing
* there could be a state between invoked and auto for autoplay, but if not
autoplay implies preload=auto
* in the invoked state, a conservative buffering strategy is used by
default
* when paused in the invoked state, we need to agree on what should happen
If we could agree, then of course it should be documented somewhere, even
if it seems somewhat restrictive of the spec to mandate an exact behavior.
--
Philip Jägenstedt
Core Developer
Opera Software
