On 04/04/2013 15:41 , Simon Pieters wrote:
On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon <ro...@w3.org> wrote:
On 29/03/2013 21:08 , Jonas Sicking wrote:
* Cache both files (poor bandwidth)
* We could enable some way of flagging which context different URLs
are expected to be used in. That way the UA can send the normal
content negotiation headers for images vs media files. I'm not sure
that this is worth it though given how few websites use content
negotiation headers.
* Use script to detect which formats are supported by the UA and then
use cacheURL to add the appropriate URL to the cache.
* Use the NavigationController feature.
* Use UA-string detection. You can either send different manifests
that point to different URLs for the media, or use a single manifest
but do the UA detection and serve different media files from the same
media URL. This is a pretty crappy solution though.
Another option: in your list of URLs to cache, instead of just strings
you can also have objects of the form { "video/webm": "kittens.webm",
"video/evil": "dead-kittens.mv4" } that would operate in a manner
modelled on <source>, caching only what's needed.
Is this intended only for <video> resources, or arbitrary resources?
Non-media elements (and hence, non-media resources) don't have the
<source> mechanism, so maybe the syntax should make it clear that it's
media-specific.
I thought about that, but I don't think that's needed, really. Assume
someone did something like:
{
"shiny/new-type": "whatever.new"
, "crummy/old-type": "whatever.old"
}
Then the UA will pick one to cache. Worst case scenario, this is useless
but harmless. But it's conceivable that script could then look at what's
in the cache to know which to use.
Just to be clear: I don't think that using this for non-media cases will
be incredibly useful. But I don't see any reason to actively prevent it.
--
Robin Berjon - http://berjon.com/ - @robinberjon
