Mountain View Meeting
From Fixing Application Cache Community Group
23 August 2012, Mozilla HQ.
Minutes are reproduced below verbatim for archiving purposes. Original minutes available here: https://etherpad.mozilla.org/appcache.
Notes from last week's sessiohttps://etherpad.mozilla.org/appcache-london https://github.com/fixing-appcache/offline-cs/tree/gh-pages/manifests -> "app cache solves some of the problems developers are facing, but not all of them" Action Items Take discussion to a mailing list (HTML WG or http://www.w3.org/community/fixing-appcache/) Adrian to look into getting a new list on HTML WG Tobie to see if it's possible to work inside HTML WG Clarify and write up problems and proposed solutions below Attendees Adrian Bateman, Microsoft Tobie Langel, Facebook Joe Stagner, Mozilla Michael Nordman, Chrome @ Google Chris Wilson, Chrome @ Google Manuel Deschamps, Twitter, HTML client Lucas Adamski, Security @ Moz Jan Varga, Mozilla Jonas Sicking, Mozilla Jason Duell, Mozilla Andrew Overholt, Mozilla Goals app development cases studies ensure people are aware of W3C bugs that exist https://www.w3.org/Bugs/Public/ http://goo.gl/JrK8Z can layout an evolutionary path for app cache Hixie has a roadmap in mind get people involved in the Fixing App Cache community group at W3C http://www.w3.org/community/fixing-appcache/ hopefully easier for some than HTML WG draft charter: http://www.w3.org/community/fixing-appcache/draft-charter-2012-08-15/ Mobile Twitter client (Manuel) successful use of app cache especially now that mobile browsers support necessary APIs history API has helped a lot some assets inlined -> big performance improvements large intersection between app users and mobile web users permalinks are very important app launch time very important daily deployments don't seem to negatively affect app cache effectiveness 90% of users are running latest version and it's app cached (went to 94% after a week of no deployments) after deployment, drops to ~60%; 40% are using an older, app cached version security need a way to force updates to latest version (not just Twitter, GMail mobile seems to use it, too) transitions from signed-out to signed-in causes cache issues multiple users using same browser (Facebook concerned about this) not a big deal if the resources are on the device and accessible through devtools, as long as it's not displayed by accident in the normal web UI app architecture all ajax (only hit server for data) when it was small: one bundle of js, one bundle of css, etc. now larger: split into two bundles ~half of the app inlined tweets are permalinks -> different master entries also use local storage for holding user data latency is a big pain point (especially for certain countries) Yahoo email client more concerned with entirely offline mode at Twitter, not super-concerned with user being offline, more concerned with speed use app cache 'cause it provides more control of caching Can't use fallback to handle tweet pages because it hits network first and only uses appcache if that fails would like to be able to explicitly flush app cache upon user logout, for example experiments with custom caching showed app cache is better Not using on desktop because: need to guarantee running latest version (security concerns) Facebook experimented with app cache due to poor http cache on some devices lots of tricks to get specific things cached and not other things There's bugs where the http status/headers look different when returned from appcache Outlook Web Access (not outlook.com) (Adrian) app cache is not totally busted :) definitely some issues that required workarounds only works in IE 10 ATM due to requirement of caching master page https://www.w3.org/Bugs/Public/show_bug.cgi?id=13168 have a config option upon installation to not use app cache at all switching between full-/semi-cache modes difficult it's a problem that manifests can only be linked to in the markup. Rather than being able to enable appcache after the page has been loaded Want to enable two "different apps". One which is offlinable, and one that's still online but faster. So two different manifests which are dynamically chosen. However still uses the same "start page" URL. Want to control when the browser looks for updates and downloads updates. One reason this is needed is to avoid consuming network bandwidth when the app needs it. Better control over FALLBACK matching URL ending in / vs. not ending in / remove swapCache from spec Expose errors to JS, for example which resource failed to load useful for collecting and aggregating, etc. to know what caused issue want to delete entire app cache from JS version numbering of manifest files (not its URL) version individual resources in manifest today: getting manifest file and see it's updated, you kick off refresh of all resources want to avoid doing if-modified-since requests to all individual resources save network use ~incremental update possibly programmatically add/remove individual resources from appcache hierarchy of manifests better granularity for updates Other apps include username/unique id in app cache manifest store .js in localStorage, small script in index contacts server upon load and gets diff of .js, evals it Major use cases caching resources (essentially UI of app) (app use cases) better control over http cache set priorities, etc. make web pages available offline is this a browser feature? some apps want to do this, too (ex. storing off-origin content, too) What app cache basically is (Tobie) 1. asset store 2. proxy for loading resources Fix app cache scope it properly and limit this scope enhance a few areas in not necessarily backwards compatible ways use signature line to ensure new features are used by UAs that support them preference seems to be for evolving what we currently have improve developer porcelain while keeping majority of existing plumbing ex. no manifest (I think?) don't shoe horn everything into app cache expose to JS: "is this page served from cache?" prefer online seems to be frowned upon (but not by everybody) update policies look at Atom/RSS for this when you make an etag request, can request a diff and server can respond with a diff Andrew Tridgell of rsync has an algorithm diff would also include an etag with the different set of bytes handling of nostore header Developer tools show which version of asset we're using (from cache, this version, etc.) Other problems that need to be addressed storing user data for offline use legal/security issues of offline storage Tobie's issues solved by no master entry and diff idea (so locally-modified stuff wouldn't match checksum and thus whole new copy would be downloaded (I think)) sessions for app cache (roughly maps to user login/logout) requirement for SSL assets to come from same domain master page (?) know what requests of server are being made on behalf of app cache vs. explicit user requests "Master entries" are a very confusing concept scoping of app cache focus on things we want to do and not on things we don't want to do cache timeout on manifest load local resources from HTML (rather than using app cache as a proxy) screenshot API how to react to AJAX requests unified quota for offline storage (except offlineStorage ;) expand JS APIs exposed for app cache disambiguate which resource to retreive when more than one cache hit for the same url are available in the appcache poor connectivity is worse than offline fast mode (new name for normal mode; as opposed to prefer online) is great for mobile High-level ideas for what we want appcache v2 to contain Get rid of master entries concept When navigating, look for an appcache which contains that URL, rather than look for an appcache which has that URL as master entry. (we do already) Would require enumerating which URLs the appcache should "capture". If there are multiple appcaches that capture the same URL, use the one which contains the most recent entry (was updated most recently?). (we do already) JS-API for adding/removing/enumerating entries (there is the mozAdd/mozDelete/mozItem API on applicationCache) JS-API for creating/deleting/enumerating appcaches https://bugs.webkit.org/show_bug.cgi?id=67135 The chrome INTERCEPT section http://code.google.com/p/chromium/issues/detail?id=101565 Knowing if you're being served from appcache or not. And which version of the appcache. We'd have to add an official version indicator in the manifest which is exposed through JS-API. Sticking the etag in the appcache manifest allows not doing if-modified-since requests for all non-updated resources. http://blog.sethladd.com/2010/10/proposal-to-enhance-html5-app-cache.html Having an expiration time in the appcache manifest makes sure that user isn't running an old exploitable version. The syntax for fallback, which mixes "follow this network-stat rule" and "cache this resource" in one rule is confusing. Ability to write a HTTP server in JS which handle URI spaces. http://www.w3.org/TR/DataCache/ http://code.google.com/p/chromium/issues/detail?id=101800 Network:* should be default mode