RE: DOM Storage feedback

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Wednesday, June 18, 2008 10:38 PM
> To: Zhenbin Xu
> Cc: Ian Hickson; public-html-comments@w3.org; public-html@w3.org;
> Sunava Dutta; IE8 Core AJAX SWAT Team
> Subject: 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.
>
>

[Zhenbin Xu] Interesting - this is precisely what we meant by async model - storage is asynchronous but the API appears synchronous.  Either the spec has changed or we may have read the spec incorrectly? Previously the spec stated that the setItem operation has to guarantee atomic operation, which we read it to mean guaranteed to be on persist store (disk or cloud).   If this is not the case, then we are in agreement here.  Since we thought we differed from the spec, we added the event to compensate for it.  We don't feel it is important event but it may be useful.




> > > > 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.
>

[Zhenbin Xu]  Here is the concern:

     localStorage['email-subject-' + id] = getSubject();
     localStorage['email-from-' + id] = resolveEmailias(from);
     localStorage['email-to-' + id] = resolveEmailalis(to);
     localStorage['email-body-' + id] = getBody();

If resolveEmailAlias throws an exception, we would have partially persisted states. Yes you can work around it by assigning results to temporary variables but it is simpler to provide begin() and commit() to the page author, especially considering there can be complex logic between states. E.g

        localStorage.begin();
        Component1FromDeveloper1();     // local storage operation inside
        Component2FromDeveloper2();     // local storage operation inside
        localStorage.commit();

Having begin/commit would allow better distributed, componentized development.








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

Received on Friday, 20 June 2008 03:08:29 UTC