Fwd: Re: App Cache

Forwarding to www-tag

-------- Original Message --------
Subject: 	Re: App Cache
Date: 	Mon, 11 Jun 2012 07:57:57 -0400 (EDT)
From: 	Yves Lafon <ylafon@w3.org>
To: 	Robin Berjon <robin@berjon.com>
CC: 	ashok.malhotra@oracle.com



On Mon, 30 Apr 2012, Robin Berjon wrote:

A bit late, but depiling email after some weeks off and not being able to
type for a while :/

>  Hi Ashok,
>
>  On Apr 27, 2012, at 15:47 , ashok malhotra wrote:
>>  You have an action item re. AppCache so i thought I would set down my
>>  thoughts.  We can discuss later if you wish.
>>
>>  I see two primary requirements for Local Storage:
>>  1. Be able to store personal information and use it with WebApps.
>>  2. Allow Apps to run connected or disconnected seamlessly.
>>
>>  There is no reason why AppCache cannot be used for 1.  You simply write
>>  a manifest naming a file, say myMedicalData.html.  This file can be different
>>  for each user.  The App will use your file with this name.when it runs on your
>>  machine.
>
>  You could do that, but you would be making life hard for yourself for no obvious reason!
>
>>  But, I don't think AppCache is used in this way.  I am not sure why.  Perhaps
>>  because, the files named in the manifest are only used if the App is running disconnected.

>  It's perfectly possible to use user-specific files in AppCache, and I
>  expect that people would do that for instance for licence keys (or
>  supercookies). But it's not a very goo data store.

First the AppCache manifest is always used, even in connected mode. It is
a way to optimize the load of the app even if a new one will be on its way
soon.
As I said earlier, ideally the appcache should be considered as special
coherence rules of a set of cached resource representations.
If you push this vision of it, then you might even say that doing POST and
PUT through that proxy/cache in disconnected ops could be the way to use
it as local storage, but it would be cheating if you are connected, and
would lead to state coherence when you go from disconnected/connected
modes.

>  First you'll have the problem that your app can't write back to the file.The server can, but that requires:
>
>  ? A trip to the server.
>  ? Updating that file.
>  ? Updating the manifest file (otherwise no other change in the application can be taken into account).
>  ? Getting the browser to reload the manifest (this has to be done separately from reloading the rest ? so long as it hasn't change the UA will get everything else straight from cache).
>  ? Getting the browser to reload your file.
>
>  It seems a lot simpler to just use local storage ? or anything else for that matter!

Clearly, leaving things separated make things simpler. Local stuff needed
by the app =>  local storage (Note that local stuff might be synchronized
with the server at some point, but it's mostly local state).

Remote stuff (apps code, apps data, coherence between all elements,
including user-specific data _readonly_) =>  appcache.
I say readonly user-specific data for appcache as dynamic read/write data
retrieved by the app should not be part of appcache.

>  I really think that AppCache should not be considered as part of the
>  local storage work. Yes, it can be hacked in such a way that it could be
>  used for such purposes, but it's already hard enough to use for things
>  that it was designed to do, twisting it to do anything else is nothing
>  short of madness :) AppCache is an optimisation tech and a code
>  distribution tech ? but it's not about local DB storage.

+1

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves