[whatwg] Application cache feedback and application local storage features feedback

[Ian Hickson]

On Wed, 23 Sep 2009, Anne van Kesteren wrote:
>
> If you use a fallback namespace it will always try to do a network fetch 
> before using the fallback entry so why is there a need for a NETWORK 
> entry in the cache manifest?

On Wed, 23 Sep 2009, Michael Nordman wrote:
>
> For cases where you don't want to, or can't, 'fallback' on a cached 
> resource.
>
> ex 1.
> http://server/get/realtime/results/from/the/outside/world
> ex 2.
> 
> http://server/change/some/state/on/server/side?id=x&newValue=y
>
> Creating a fallback resource with a mock error or empty response is busy 
> work.

What Michael said.


On Thu, 24 Sep 2009, Anne van Kesteren wrote:
> 
> You could fallback to a non-existing fallback or some such.

No, that would prevent the application cache ever getting cached, IIRC.


> But if it is really needed NETWORK should get priority over FALLBACK in 
> my opinion (or at least the subset of NETWORK that is not a wildcard)

Done.

Resources that are actually in the cache still win over the offline 
whitelist namespace.


On Wed, 23 Sep 2009, Mike Hearn wrote:
> 
> I read the threads on whether local storage should be managed by the 
> browser or user with interest. I'm not sure if there was agreement on 
> this or not (didn't read the whole thing), but had an idea for one 
> solution. Namely, that local storage is indeed managed by the browser 
> automatically and can be purged at any time .... long-term client 
> persistence of web app data is instead done by letting webapps handle 
> the file->save menu item that exists in nearly every browser except 
> smartphones (see below).
> 
> The advantages of providing onfilesave="" and onfileload="" event 
> handlers are:
> 
> 1) It does not add complexity, because the user isn't expected to do any 
> more than they are today (no new ui to manage local storage etc)
> 
> 2) It is 100% compatible with users existing mental model for how they 
> export data from an application that they wish to save, back up to disk 
> etc
> 
> 3) It fixes the existing behavior of file|save for web apps which is 
> pretty useless and not what the user expects, unlike for regular web 
> pages where it does work
> 
> 4) It solves the problem of client-side backups
> 
> How could it work? In response to an onsave event, the app could return 
> a Storage object that contains the data that makes sense to persist (ie, 
> not big data files). There could be a few reserved keys for things like 
> the icon, default file name and URL to open in conjunction with that 
> "web bundle". If the user double clicks or uses file|open on such a 
> file, the browser would load the URL named in the bundle file and fire 
> the onfileload handler with that storage object.
> 
> This seems like a decent compromise between the two positions, in that 
> it'd let you make traditional desktop-style apps written in HTML as 
> Apple want, but for pure "cloud" apps that happen to just need more 
> local storage, the user isn't asked to do more than they are today - 
> which I personally consider vital for the evolution of the web.
> 
> What about clients where there is no user-accessible file system, like 
> smartphones or perhaps ChromeOS? Then onfilesave/onfileload can be 
> integrated with whatever other UI is wanted - for instance, perhaps 
> starring/bookmarking should trigger a save to local storage, or a basic 
> "documents associated with this web site" list could be used.
> 
> What do you think?

Applications want to save state continually, not just at user checkpoints.

Applications want to save state without the user really knowing that it is 
state.

So I don't think this really solves the problem.

Also at this point IE8 has shipped the localStorage API, so I think we're 
basically stuck with it.


On Wed, 23 Sep 2009, Mike Hearn wrote:
> 
> 3) Doesn't solve the fact that file|save doesn't work for web apps

I think it's wrong to think of Web Apps as distinct from Documents. Is 
a Google Search results page an Application or a Document? It might want 
to save state, e.g. to remember whether you want Safe Search enabled or 
not. Should you have to do File | Save to save that state? What about if 
you want to save the results of a search to a file?


On Wed, 23 Sep 2009, Michael Nordman wrote:
>
> Food for thought around the AppCache feature which can be similarly 
> affected i think.
> 
> ---------- Forwarded message ----------
> From: emu <emu.huang at gmail.com>
> Date: Sun, Sep 20, 2009 at 8:31 AM
> Subject: [gears-users] Version in manifest is not enough
> To: Gears Users <gears-users at googlegroups.com>
> 
> Some times the response of the web server be changed by some proxy 
> servers or even the ISPs(some times they try to add some ads or filter 
> something), and google gears will cache the changed content an will not 
> check before the manifest file change again, and some times the manifest 
> files change before the files they list changed because of the CDN 
> problem. When these happends, wrong captured files becomes a disaster. 
> It's very hard to findout what happends to the clients' browser.

The App Cache model downloads the manifest before and after the cache, and 
only if the file has not changed in between does it actually use the new 
files. If the cache changed, it blows everything away and tries again.

Now if the CDN is such that different files are at different versions, 
then you have problems whether or not you are using appcache. Just going 
to the site could result in the user seeing a mishmash of new and old 
files. Don't do that. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'