Re: Fixing appcache: a proposal to get us started

On Wed, Apr 3, 2013 at 5:50 AM, 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.
>
> It's a bit verbose, but it's a lot less verbose than loading the content
> twice.

Yes. The proposal already suggests using objects to express individual
resources. Something like the above seems like a natural extension.
Audio and video in general will be tricky until there's a set of
codecs that can be universally depended on. We'd likely have to deal
with video players written in flash too :(

/ Jonas

Received on Wednesday, 1 May 2013 04:15:02 UTC