Mountain View Meeting

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