On 11/11/2011 12:24 PM, Tab Atkins Jr. wrote:
On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra
<ashok.malho...@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.
This is something being examined with web intents, I'm sure, as an
extension of the postMessage concept. AFAIK, postMessage works
just fine for this. Site (a) receives messages and checks storage, and
sends responses, Site (b) includes Site (a) in an iframe. Everybody wins.
More exciting is that postMessage can work with typed arrays and it
seems blob uris can be shared across sites.
I'd expect something to catch-on, in the open market, much as
gravatar.com has.
I think this is going to be simpler than OpenID in the long run.
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.
IndexedDB is certainly better than localStorage.
It'd be nice if IDB had a default key/value store already setup or a
shortcut to create one.
It takes a good 10 lines to prepare things for a simple key/value table,
where localStorage does not.
Those are for: open, version, create, transaction, error callbacks.
They're all necessary of course,
for heavy work. But as a replacement for localStorage, it's an
additional 40 lines of code.
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*.
I agree, these seem like serialization issues, nothing much related to
data storage.
I am looking forward to creative uses of IDB to handle relational data.
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.
There's certainly a big gray area on how UAs are going to approach this.
Some part
of this profile / preferences talk may belong in the DAP working group.
As a tangent:
Will UAs offer remote storage of localStorage, IndexedDB, applciation
cache and the like?
I've certainly read from engineers that backup is something that
applications can do better than any general mechanism.
Even with poor efficiency, it might be a value-added service that UAs
decide to jump into.
In the meantime, big vendors are already offering "cloud" storage for
application vendors.
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.
Is IndexedDB working with array buffers / blobs yet?
It's been a rough few years with local storage; sending base64 encoded
binary strings into a UTF-16 encoded database.
I can't even use the browser's btoa and atob methods.
-Charles
