RE: DOM Storage feedback

On Mon, 23 Jun 2008, Zhenbin Xu wrote:
> > >
> > > 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.
>
> 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?

That's up to the author. (You could just as easily simply use the ID that 
the server gives you, in fact, in which case you wouldn't need this 
locking mechanism at all and could just use one key to confirm that the 
others have been added, so long as you always set that one last.)


> > 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.
> 
> Script cannot really support transaction without the platform exposing 
> it.

The examples I've shown clearly indicate that this is not the case...


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

Why not? I don't see how the demo script would fail in case of power 
failure or OOM. It would not clean up after itself, but the author could 
easily create a simple script that just goes through and does cleanup in 
the unlikely case of the author caring about stray data.


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

I've demonstrated that you can build transaction support on top of the 
existing DOM Storage API. As others have pointed out, a name/value pair 
API is woefully inadequate for any sort of serious e-mail application.

At this point there really isn't a compelling reason to complicate the API 
with transaction support (especially the limited and somewhat brittle 
transaction support IE8 has).

I know I've asked this before, but it would be reassuring to everyone 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 don't want to confuse authors on 
the platform who might test in one browser and find things don't work in 
another browser. Sorry for asking this multiple times but you haven't 
replied to it yet so I don't know if you've seen the request. 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:40:03 UTC