Re: Fixing appcache: a proposal to get us started

On 04/04/2013 15:41 , Simon Pieters wrote:
> On Wed, 03 Apr 2013 14:50:53 +0200, Robin Berjon <robin@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

Received on Thursday, 4 April 2013 13:58:09 UTC