Re: Last Call Comments on Web Storage

Ashok - your comment has been added to the comment tracking document for 
this LC:

http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-1

If you want to propose extensions or changes to Web Storage, please use 
[Bugzilla] and please feel free to contribute to the group's [Database] 
wiki.

If you have any additional feedback, please reply by November 25, the 
day the CfC to publish a Candidate Recommendation for Web Storage ends 
[CfC].

-Art Barstow

[Bugzilla] 
http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG
[Database] http://www.w3.org/2008/webapps/wiki/Database
[CfC] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html


On 11/14/11 5:44 PM, ext Arthur Barstow 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
> [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 Friday, 18 November 2011 15:01:23 UTC