Re: Fixing appcache: a proposal to get us started

Come on!? Deal with flash players seems to me like a regression.


On Wed, May 1, 2013 at 1:14 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>