RE: DOM Storage feedback

It would be useful to get feedback from other implementors on this.

On Wed, 18 Jun 2008, Zhenbin Xu wrote:
> 
> [Don't know what is the alias for WHATWG Mailing List, please add when 
> reply].

Unless you're subscribed, e-mails to whatwg@whatwg.org will bounce, so I 
haven't added it back. I have, however, cc'ed public-html@w3.org, which 
has more subscribers than public-html-comments.


> > The API is designed in such a way that UAs can implement a lazy commit 
> > on the back end, but this should not be exposed to the author -- there 
> > is no reason for the author to need to know whether the data is in 
> > RAM, flash storage, disk storage, remote tape storage, or whatever.
> 
> 
> There is clearly an advantage to expose this concept to authors -- just 
> like they need to know network can be slow so better use async XHR 
> rather than sync XHR -- storage operation can be very slow. Sync DOM 
> Storage operation is a potential hang point,

The idea is that the storage is asynchronous (and under the control of the 
UA), but that the API appears synchronous. That is, as soon as one script 
sets a storage item to a particular value, the setter will return with no 
latency, and all attempts from any frames to read that same storage item 
will give the new value back. It doesn't have to be stored to disk 
immediately, however. Since this is a simple name/value text-only API, it 
is trivially cached in memory.

What's the use case for the event saying when the item actually hits the 
disk? Also, what would that actually mean? The "disk" could be up in the 
cloud (e.g. the user could have mounted an Amazon S3 service account as a 
local disk), in which case the Web browser really has no idea when the 
bytes have hit the raw iron.


> > > Storage.begin()
> > >
> > > Storage.commit()
> >
> > In particular, these methods and the associated events should not be 
> > provided to authors. The SQL database API is already capable of 
> > handlign this. Authors who wish to have transactions are almost 
> > certainly going to want other features too, such as types, database 
> > schemas, etc.
> >
> > If you insist on keeping these features, please do mark them as 
> > Microsoft-proprietary by prefixing them with "ms" or some such, as in, 
> > "msBegin()", "msCommit()", etc, so that authors can clearly see that 
> > these APIs are non-standard, and so that we don't have any conflicts 
> > with future extensions to the API.
> 
> I have to disagree that customers who wants begin()/commit() should use 
> SQL API.  If the argument holds, why not simply get rid of DOM Storage 
> feature completely since customer can just use SQL API?

This was considered, but there seemed to be a need for a middle ground 
between cookies and a full SQL-like database. Also, the DOM Storage 
sessionStorage feature has no analogy in the SQL Database API.

The features that distinguish the DOM Storage API from the SQL Database 
API are that the API appears synchronous, allowing much simpler 
interaction between frames; that the API supports a sessionStorage 
feature; and that the DOM Storage mechanism is significantly simpler and 
thus provides a much lower barrier to entry.


> This request come from one of our top customers when we discuss about 
> adoption of DOM Storage feature. They really want to make sure their 
> state is consistent without going through a lot of extra efforts.

Could you elaborate on the use cases?

It would also be interesting to hear from other browser vendors on their 
opinions on this.


> For instance, to cache an email, you would want to cache complete 
> headers (e.g. From, To, Subject, Sent) and body instead of only part of 
> them.

For e-mail storage, you really want to use a database mechanism, not the 
name/value pairs. Using the DOM Storage API for e-mails is like using a 
paper bag as a shipping crate.


> Without begin/commit they would have to either concat them or make sure 
> the storage writing statements are grouped together and 
> non-interruptible, a limitation could have been avoid with begin/commit.

In principle, short of a user interruption, any DOM Storage setters given 
in a row are guaranteed to always be added together without interference, 
so that doesn't seem like a problem.

Also, if the main use case is caching data, then it is reasonably easy to 
use the simple API to provide a transaction-like mechanism:

   // run this first, in one script block
   var id = localStorage['last-id'] + 1;
   localStorage['last-id'] = id;
   localStorage['email-ready-' + id] = "0"; // "begin"

   // these can run each in separate script blocks as desired
   localStorage['email-subject-' + id] = subject;
   localStorage['email-from-' + id] = from;
   localStorage['email-to-' + id] = to;
   localStorage['email-body-' + id] = body;

   // run this last
   localStorage['email-ready-' + id] = "1"; // "commit"

An author could easily wrap this up providing custom begin() and commit() 
functions if desired. I don't see what having them in the API gains us, 
really, other than extra complexity for UAs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 19 June 2008 05:39:10 UTC