Re: Last Call Comments on Web Storage

On 11/11/2011 12:24 PM, 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.

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

Received on Friday, 11 November 2011 22:06:18 UTC