Re: Fixing appcache: a proposal to get us started

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.

e.g.:

MEDIA
kittens.webm video/webm; codecs="..."
kittens.mp4 video/mp4; codecs="..."

# one MEDIA block per resource?

This doesn't include the media="" attribute of <source>, but I think that  
should be dropped from the element anyway.

Something similar could be done for <img srcset>, maybe, which is a  
different beast than <source>.

> It's a bit verbose, but it's a lot less verbose than loading the content  
> twice.
>


-- 
Simon Pieters
Opera Software

Received on Thursday, 4 April 2013 13:41:36 UTC