Warning:
This wiki has been archived and is now read-only.
Second London Meeting
From Fixing Application Cache Community Group
8 February 2013, Google Office.
Minutes are reproduced below verbatim for archiving purposes. Original minutes available here: https://docs.google.com/document/d/15xIoWnXT3Vpo-QZv_vspAj2bf55nhwRqXahPh0CX3Z8/edit.
Attendees: Chris Wilson <cwilso@google.com> Robin Berjon <robin@w3.org>, Alex Russell <slightlyoff@google.com>, Anne van Kesteren <annevk@annevk.nl>, Andrew Overholt <overholt@mozilla.com>, Mounir Lamouri <mounir@lamouri.fr>, Michael Nordman <michaeln@google.com>, Jake Archibald <jaffathecake@gmail.com>, Sam Dutton <dutton@google.com>, Henri Sivonen <hsivonen@hsivonen.fi> Jonas Sicking <jonas@sicking.cc> Jan Varga (Mozilla) <janv@mozilla.com> Andrew Betts (FT) <andrew.betts@ft.com> Rowan Beentje (FT) <rowan.beentje@ft.com> Regrets: Tobie Langel <tobie@fb.com> Beginning with discussion of Google design sketch (https://github.com/slightlyoff/NavigationController/) ‘spec has too much magic in it’ ‘expressing multiple things at the same time’ (well intentioned but problematic) Controller is attempt to cope with problems, not appcache / no appcache - what is the plumbing you would need? - what escape hatches do you need? ‘some of us abandoned ship on appcache’ need ‘division of labour’: appcache ‘mangles it all together’, need to ‘mentally untangle’ AR: Like a shared worker - instantiated in a different process, does not have scripted access directly to document or other API. If you navigate away, it has nothing to say about that; it’s only involved in navigations in this context. Lifecycle of controller is an interesting topic. Would need to be defined. JS: in what cases do you want to add/remove entries from the cache? JA: at Lanyrd, our mobile needed to update/”subscribe to event” AR: popping up a level: general scenario, taking Wikipedia offline (in total) is nonsensical; would want “take this offline” feature for data, while keeping program cached. Current appcache design prejudices to treat URI things as program code, while presuming data is all stored in other local storage (non-URI based). Attempting to take the whole of something like Wikipedia offline is insane -- it’s a 4GB gzip! Need to treat this kind of content as a graph of nodes, a library of content -- some of which you want. Every resource should have a URL -- page, media, app -- storing resources as serialised data in local storage (of some kind) is problematic, ‘URL-hostile’. AR: Should URL-friendliness be a goal? I think it should. HS: would you expect Wikipedia to cache their navigation HTML separate from content HTML? For offline (at present) developers are treating the ‘shell’ of a page as something static. HS: Wikipedia has content URLs and navigation URLs. Should they be separating their content and navigation URLs? AR: ‘What is the right unit of offline-ibility?’ AR: They should be separating those two. They do this today, they’re just doing it on the server. They will have to go through this process like any other app. CSS query to check if resource available reliably offline. Crawlers? AR: This is where URL-friendliness gets really good. Want to be able to navigate to any URL, but when you’re offline, you should be able to get a reasonable experience. AR: a cache containing other caches JS: presents https://etherpad.mozilla.org/NON7Z6r3UP proposal JS: capture feature may not be needed AR: this is what we describe as “routing” - does capture work with cross-origin resources? JS: likely, haven’t really thought through AR: there’s a mapping between longest-prefix match and controller JS: capture is optional, not even sure it’s needed - but it’s not entirely thought through. It’s an escape vector from the default logic. JS: map is interesting - if you end with *, it’s a prefix match. AR: similar to how we were thinking of registering controllers JS: twitter doesn’t fit this model with their current URL model - because their tweet status URLs don’t match the prefix-match model. AR: Currently only your controller and a default: no ‘Russian doll’. More atomic? JS: “worker” example (#3) is a local controller example cookie-vary helps identify URLs that also depend on a cookie value (Twitter scenario) what feature set can we make declarative? AR: a list of (multiple, separate) named caches JA: serve different data based on UA JS: only checking the manifest to see if I need to make any other checks is great when it works, but has severe downside of “I have to remember to update my manifest” Using ETags ‘with sensitivity’ JA: method to get ETag from cache item HS: If the HTTP cache is seen as an unmaintained feature, Web devs will use a more complex thing just to fight the HTTP cache eviction policy. We should make sure that apps the user uses all the time don’t need to fight the HTTP cache eviction policy. Eviction policy? AR: Infobars and prompts may be appropriate But -- devs don’t want to use stuff that results in prompts to users AB: ‘incremental privileges’ -- problem with prompt for every storage API - Sort of fixed in Firefox, enumerated privileges (user not prompted until APIs used) CW: user may want to manage storage of content such as movies (gigabytes), but not care about app data (megabytes) RB: maybe we should drop proposals for inter-app communication (CW: to avoid attempting to boil all the oceans...) JS: “expiration” feature - if the cache is older than x, then download first, rather than render from the cache first. JA: posted https://gist.github.com/anonymous/2413617524edb6fd7f1f, line 32: listening to request for fallback Heuristic caching (JA: Dev Tools?) Complementary feature sets: declarative and API AR: telemetry will reveal more (HS: but this is only available to companies like Google or Twitter :^/) AR: We should be able to explain everything in appcache v1 in terms of our imperative solution - though it may not be user-implementable that way. JA: idea of declaring controller as HTTP header HTML element attribute? AB: what’s the trouble with headers? people have trouble using headers - AR: CORS is hard to use in practice due to header req. JA: On a controller, should we enable users to generate responses from a string? AR: In one design, we only allowed responses through cache URLs. You could still do this with a data: URL, but it was more challenging. But this seems common enough to want it to be a first-class feature. Blobs, strings, URLs from cache, req/response headers. AR: from XHR, we need ‘a more coherent response type than we’ve currently got’ AR: ‘opportunities for XSS are rife’ fetch cross-origin entries with CORS Updating even when not on a page: spawn the controller, please update whatever you need to update! Maybe this should require user permission? Tell me if an update is available; download an update (need progress events); What if attempting to update when offline? If I go to an app like Gmail a lot, I want to be able to specify that I want it to work offline: not just to store app data, but messages as well AR: Trying to get to a point where app and URL is a collaboration, not a source of competition/tension. HS: Do all Facebook Like button iframes share the same controller instance when embedded by different origins? AR: one controller and multiple tabs/windows -- one path? MC: Thoughts on APIs for quota and resource management once some data is actually stored? AR: we should nail down this URL-controller relationship. iframe: in terms of controller, need to treat same as opening new tab? AB: what about seamless iframe? ‘Russian doll controllers are crazy’ (general agreement) [RB: here’s a quick and dirty attempt at implementing AppCache over NavigationController: https://gist.github.com/darobin/4739167] How to handle conflicting controller scripts AR: How are we feeling about these proposals? General agreement: good, JS: want to progress both proposals simultaneously. [lots of issues filed in the NavigationController repo] Bring Your Own Unicorn Alex notices that you can write a network handler in a FF extension, thus potentially enabling prototyping this in FF more completely. Robin to fwd link. Closing Action Items: Alex to write up prose for NavigationController, make public Jonas to write up prose and find better URLspace home for mozilla proposal Chris to sync getting posted to WebApps/WHATWG together.