RE: DOM Storage feedback

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Friday, June 20, 2008 3:16 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
>
> On Fri, 20 Jun 2008, Zhenbin Xu wrote:
> >
> > More explicit would be nice - especially the synchronous API but
> > asynchronous storage part.
>
> Ok, I'll make a note to update this.
>
>
> > > But the problem is that the above would fail if the component from
> > > developer 2 uses .begin() or .commit(),
> >
> > This issue is commonly solved by strict coding guideline.
>
> An API that _requires_ strict coding guidelines to be usefully used is
> not
> a well designed API, and it is _esepcially_ not a good API for the Web.
>
>
> > > Right now you can avoid all these problems by just doing:
> > >
> > >    var success = false;
> > >    try {
> > >      var id = localStorage['last-id'] + 1;
> > >      localStorage['last-id'] = id;
> > >      localStorage['email-ready-' + id] = "0"; // "begin"
> > >
> > >      localStorage['email-subject-' + id] = getSubject();
> > >      localStorage['email-from-' + id] = resolveEmailAlias(from);
> > >      localStorage['email-to-' + id] = resolveEmailAlias(to);
> > >      localStorage['email-body-' + id] = getBody();
> > >
> > >      success = true;
> > >    } catch (e) {
> > >      // report or resolve e if necessary
> >
> > Not easy for script recover from exception. Either some garbage are
> left
> > in localStorage, or a more complex scheme is needed.
>
> Not at all, my examples all had recovery that removed the bogus
> content:
>
> > >    }
> > >    if (success) {
> > >      localStorage['email-ready-' + id] = "1"; // "commit"
> > >    } else {
> > >      localStorage.removeItem('email-subject-' + id);
> > >      localStorage.removeItem('email-from-' + id);
> > >      localStorage.removeItem('email-to-' + id);
> > >      localStorage.removeItem('email-body-' + id);
> > >      localStorage.removeItem('email-ready-' + id); // "cancel"
> > >    }
> > >
> > > This can easily be wrapped into a utility method that takes a
> single
> > > method as its only argument:
> > >
> > >    function transactionAdd(body) {
> > >      var success = false;
> > >      var keys = [];
> > >      try {
> > >        var id = localStorage['last-id'] + 1;
> >
> > If the id is persisting on disk and ever increasing, there is a
> danger
> > of overflow. So a more elaborated scheme may be needed here.
>
> You'd have to be increasing the ID one hundred times per second for
> over
> two million years to overflow the integer range of the JS Number type.
> I
> don't think that's a problem.
>
>
> > >        localStorage['last-id'] = id;
> > >        localStorage['block-' + id] = "0"; // "begin"
> > >
> > >        body(function (name, value) {
> > >          localStorage['block-' + id + '-' + name] = value;
> > >          keys.push(name);
> > >        });
> > >
> > >        success = true;
> > >      } catch (e) {
> > >        // report or resolve e if necessary
> >
> > It is difficult to do any meaningful error handling inside an utility
> > function since it lacks context. Better leave it to the callers who
> have
> > more information about the situation.
>
> The utility function could be adjusted as needed. For the example I
> gave,
> the function handled the errors fine, I don't really see a problem.
>
>
> > >      }
> > >      if (success) {
> > >        localStorage['block-' + id] = "1"; // "commit"
> > >      } else {
> > >        for (var i in keys)
> > >          localStorage.removeItem('block-' + id + '-' + keys[i]);
> > >        localStorage.removeItem('block-' + id); // "cancel"
> > >      }
> > >      return success;
> > >    }
> > >
> > > You would use this like this:
> > >
> > >    transactionAdd(function(add) {
> > >      add('subject', getSubject());
> > >      add('from', resolveEmailAlias(from));
> > >      add('to', resolveEmailAlias(to));
> > >      add('body', getBody());
> > >    });
> > >
> >
> > How would application retrieve particular item later given that it
> has
> > no knowledge of what block id is?
>
> Oops, the end of the utility function should be:
>
>    if (success)
>      return id;
>    return 0;
>
> ...and the caller should store transactionAdd()'s return value.
>
>


[Zhenbin Xu]
And the id is going to be posted back to the server so next time it can be
used?  Or would the ids need to be persisted on the client side in a separate
localStorage area?




> > If a wrapper function is needed all the time, why not make it as part
> of
> > the platform?
>
> Because it's not needed. When a transaction API is actually needed, the
> Database API is the one that should be used (and it has support for
> transactions built-in as a first-class object). The DOM Storage API
> isn't
> supposed to be used for structured data, it's just a name/value pair
> API.
> I'm just showing that it _can_ support transactions if someone really
> wants to do it.
>
>

[Zhenbin Xu] Script cannot really support transaction without the platform exposing it.
A transaction needs to be resistant to all type of exceptional conditions (OOM,
Power failure, etc.) and clearly the above script cannot provide that kind of guarantee.

I don't agree transaction has to be tied with SQL statements, like the
Database API.  The email scenario already demonstrated that there is
a need for transaction without using SQL.




> Again, please, if you could commit to either removing or renaming (with
> an
> "ms" prefix) the non-standard event and methods that you implemented in
> IE8 to indicate that they are proprietary extensions, we would really
> appreciate it. We don't want to confuse authors on the platform who
> might
> test in one browser and find things don't work in another browser.
> Thanks!
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'

Received on Tuesday, 24 June 2008 00:21:37 UTC