On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra
<[email protected]> 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
