W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Last Call Comments on Web Storage

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 14 Nov 2011 17:44:55 -0500
Message-ID: <4EC199E7.3020900@nokia.com>
To: Tab Atkins <jackalmage@gmail.com>, ashok.malhotra@oracle.com
CC: public-webapps@w3.org
Hi Ashok,

I agree with Tab's comments and wanted to mention some of the related 
history ...

The relationships between WebApps' various database related specs has 
been discussed before and [DB-wiki] was created to help clarify the 
relationships. The good news is there are now 2 specs rather than 4 but 
the wiki is a bit outdated so I recorded [Action-640] as a reminder to 
update it during Web Storage's CR period and inputs/updates from others 
is welcome.

Additionally, because of some concerns about what I would call 
"shortcomings" of Web Storage when compared with IDB, last June we held 
a poll [RfC-Storage] to determine if there was consensus to continue 
work on that spec or to stop work on it (and to publish it as a WG 
Note). The consensus was to continue to move the spec to REC.

-Art Barstow

[DB-wiki] http://www.w3.org/2008/webapps/wiki/Database
[RfC-Storage] 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html
[Action-640] http://www.w3.org/2008/webapps/track/actions/640


On 11/11/11 3:24 PM, ext Tab Atkins Jr. wrote:
> On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra
> <ashok.malhotra@oracle.com>  wrote:
>> o One use of local storage might be to store personal preferences,
>> such as travel preferences or personal information such as medical
>> history.  In such cases, you may want to allow several sites access
>> to this information (I prefer aisle seats; I would like to stay at
>> Marriott hotels.)  Local storage is governed by the same-origin
>> policy but in some cases it may be wise to carefully relax this and
>> allow multiple sites to access the data.
> It seems that these are *not* the sort of thing you want to leave to
> ad-hoc data storage.  Instead, this should be approached from a
> standardization perspective.
>
>
>> o When updating local storage, transactional semantics or, at
>> least, a transactional option would be desirable.
> IndexedDB is intended to be the "better" version of localStorage, and
> utilizes transactional semantics.
>
>
>> o It would be very useful to be able to map from other forms of
>> data storage, such as RDF or Relational data to RDF.  Mapping from
>> RDF would be simple.  Mapping from Relational is more challenging.
> What's the use-case for taking in RDF and storing it in localStorage?
> One can always just store RDF directly as a localStorage *value*.
>
>
>> o If local storage is used to store personal preferences or
>> personal information it would be very useful to be able to move it
>> from one device to another, say my laptop to my phone.
> This is left to either the app or the browser to achieve.
>
>
>> o Question: The values in the key-value pairs are typed as strings
>> but I presume they can be URIs and be interpreted as URIs.  Or they
>> can be large files.  Perhaps this could be clarified.
> They are always strings, but of course they can represent any type of
> data that can be stringified and revived.  The application can choose
> to interpret them as urls or files if it wishes.  However, storing
> large files is better done through the FileSystem API or through
> IndexedDB.
>
> ~TJ
>
Received on Monday, 14 November 2011 22:45:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT