- From: Brian Blakely <anewpage.media@gmail.com>
- Date: Fri, 27 Jan 2012 17:39:50 -0500
I completely agree Ian, app cache would be the means by which a developer sends their assets to the user's local storage device. This proposal deals chiefly with standardizing the messaging around that. The developer sets up the application to be ready for offline use (via App Cache, localStorage, IndexedDB, cookies, etc), and informs the UA when the user can go off the wire. The UA then informs the user in a predictable way that will become familiar to them as they continue to use that particular client. Background downloading and other mechanics introduced in this thread enable a native-like app download process that is, again, always the same on the same UA, instead of varying from application to application. -Brian On Fri, Jan 27, 2012 at 4:50 PM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 27 Jan 2012, Brian Blakely wrote: > > > > Hey Ian, > > > > "What kind of app are you considering that needs 700MB at once?" > > > > I'm considering videogames that the user would like to play offline > > (plane flight, subway, etc), as well as massive software packages like > > Adobe CS. A good application designer would allow the user to choose > > portions of the app that they would like to cache long-term, but suppose > > the user needs the entire thing? In that case, 700MB could likely > > lowballing by quite a bit. > > I think appcache handles this particular case reasonably well (modulo it's > other known limitations, anyway). The caching progress can be easily > reported to the user (either by the UA or the page), so the user can know > that they should leave the tab open while it does the update, and yet the > page is usable in the meantime. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Friday, 27 January 2012 14:39:50 UTC