Amazon People!/borismus * Things we need to change: End user experience: * Get the browser to just opportunisticly cache things when it sees a manifest, stop asking. [Fx] ** Uses the normal HTTP cache * Pin indefinitely when someone "installs" something. [Fx] ** Installed permanently * Good tools for telling the status of the cache, the manifest and when resources are pulled from the local cache instead of the web. [W3C] * Developer experience is horrible New APIs or features: * Make sure an app can remove its own cache (Multi-user computer use case) [W3C, Fx] * The ability to tell the browser that you need to go and re-check the manifest right now from JS, even if the manifest hasn't changed. [W3C] * The ability to force the reload of any particular resource, right now. [W3C] * The ability for a page to say "no incremental rendering" so that something snaps in. [Fx, W3C] * Access to app cache contents via the File API. [Fx, W3C] * Load resources explicitly from app cache - html, css, images, etc. * Make sure that the Mozilla methods that we have as extensions get merged upstream. [W3C] * Add, iterate, remove entries * Make sure when you load extra items that you can get load & error events as well. [Fx, W3C] * Being able to add an application to the OS (i.e. where they are normally placed) * by wycats; would automatically create a cache manifest based on the resources in the document (presumably everything fetched before the load event is dispatched) Changes: * Reverse the assumption from "offline apps that can access the web when you're online" * Makes content stale when it's not supposed to be * The master entry should be explicitly opt-in, and not cached by default * Want to be able to load from 3rd party data from CDNs * Want to be able to load the manifest file from CDNs * * Fundamental - If a 404 happens to any of the resources, the entire cache fails. This needs to change. [Fx, W3C] * Error, with the chance to recover? * Depends on use case - install, it's bad, opportunistic, it's fine * Fundamental - If the URL of the manifest changes, don't blow away the resources, try and re-use them - helps with cache busting * Will require a seprate identifier because of master entries being added for a single manifest * Get rid of the mime type requirement for the app cache - doesn't fit a lot of deployment scenarios. [W3C, Fx] * An update doesn't happen until the 2nd time the app is loaded. Need a way to say "Update immediately" or give the app the option. * Don't cache the master page * Sub-resources should be loaded from different origins * Explicit doesn't require same origin * Fallback does * Chrome will load from other domains, but only with the same scheme (http or https) Performance: * Performance: measure and use leveldb? [Fx] Questions: * Make sure when you add a manifest to an html file at runtime that it loads. [Fx, W3C] * Also double-check that it gets load/error events. * Any flow changes for BrowserID? [Fx] Bug: * Firefox respects no-store Cache header for cachable resources * We don't expire old cached entires when you change it * Fix Firefox bug around onUpdateReady not firing. [Fx] * * Make sure we're clearing the app cache when we clear the disk cache. [Fx] * * * Sometimes firefox doesn't deliever the update ready event for some reason * File the bug! Notes from the 11/5/2011 meeting: * The file that contains the manifest is cached and that's a problem? (Peter Lubbers?) * config.xml (Nitobi Software) * Don't use localstorage for stuff the cache * Different distribution methods - widgets solve a lot of these (Chaals?) * No headers - they suck * From the cache when you're offline, but always use the network when you're online * How do you take a page and make it available in the OS? (France telcom) * Michael Rogers (couchdb) - http caching semantics?