Re: Last Call Comments on Web Storage

I don't think it's controversial amongst practitioners that both Web
Storage and IndexedDB are useful and should exist. WebStorage is a very
simple key-value store that is useful for very common, simple cases, while
IndexedDB is a full-on database solution more appropriate for complex cases.

One thing that came up during the Offline Workshop was that Web Storage is
often used as a kludge to get around limitations in the browser's native
ability to expose resource caching to JavaScript (either via application
cache or via a new API). With that said, Web Storage would still be
extremely useful for simple user data that did not require the full
programming model of a database.

Yehuda Katz
(ph) 718.877.1325


On Mon, Nov 14, 2011 at 2:44 PM, Arthur Barstow <art.barstow@nokia.com>wrote:

> 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<http://www.w3.org/2008/webapps/wiki/Database>
> [RfC-Storage] http://lists.w3.org/Archives/**Public/public-webapps/**
> 2011AprJun/1110.html<http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html>
> [Action-640] http://www.w3.org/2008/**webapps/track/actions/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
>>
>>
>