[whatwg] Restarting the media element resource fetch algorithm after "load" event

Robert O'Callahan robert at ocallahan.org
Thu Oct 8 03:10:01 PDT 2009


http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource

In the resource fetch algorithm, after we reach the NETWORK_LOADED state in
step 3 which indicates that all the data we need to play the resource is now
available locally, we end the resource fetch algorithm. However, in Gecko we
have a media cache which might discard blocks of media data after we've
reached the NETWORK_LOADED state (to make room for data for other loading
resources). This means we might have to start fetching the resource again
later. The spec does not seem to allow for this. Do we need to change our
behavior, or does the spec need to change to accommodate our behavior? I'd
prefer not to change our behavior since I think to follow the spec we'd need
to pin the entire resource permanently in the cache after we reached
NETWORK_LOADED, which could be highly suboptimal in some situations.

Another issue is that it's not completely clear to me what is meant by
"While the user agent might still need network access to obtain parts of the
media resource<http://www.whatwg.org/specs/web-apps/current-work/#media-resource>..."
What if there is data in the resource that we don't need in order to
play through normally, but which might be needed in some special situations
(e.g., enabling subtitles, or seeking using an index), and we optimize to
not load that data unless/until we need it? In that case would we never
reach NETWORK_LOADED?

In general NETWORK_LOADED and the "load" event seem rather useless and
dangerous IMHO. If you're playing a resource that doesn't fit in your cache
then you'll certainly never reach NETWORK_LOADED, and since authors can't
know the cache size they can never rely on "load" firing. And if you allow
the cache discarding behavior I described above, authors can't rely on data
actually being present locally even after "load" has fired. I suspect many
authors will make invalid assumptions about "load" being sure to fire and
about what "load" means if it does fire. Does anyone have any use cases that
"load" actually solves?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091008/9aab1e08/attachment.htm>


More information about the whatwg mailing list