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 wrote:
> On Wed, Apr 3, 2013 at 5:50 AM, Robin Berjon 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 , 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
>
Re: Fixing appcache: a proposal to get us started
I love the idea! It is the best solution listed so far.
On Wed, Apr 3, 2013 at 9:50 AM, Robin Berjon 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 , caching only what's needed.
>
> It's a bit verbose, but it's a lot less verbose than loading the content
> twice.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
Re: Fixing appcache: a proposal to get us started
I'm writing a web application that uses the AppCache API for offline browsing. But I'm also using the Audio API to play back-ground music and a few audio effects. For audio support in different browsers I'm delivering each sound/music in two different file formats: OGG and MP3. The problem is regarding the cache manifest file. If we add all audio files (MP3 and OGG) in the cache manifest file, all browsers will cache all files. Including the unsupported ones. So, we end up with a huge storage requirement. Which is really bad if you are on a 3G connection for example. To prevent browser caching unsupported resources, the best approach I've found was to split the manifest file. This way we can tell browsers that sopport OGG files to cache only OGG files, and do tha same for other formats like MP3. But it is a "ugly solution". Now I have two manifest cache files, one with all OGG files listed (ogg.appcache) and the other one with the MP3 files (mp3.appcache). Good luck guys! Best regards, Emerson Estrella
