RE: DOM Storage feedback

Inline...

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Monday, June 23, 2008 5:39 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 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!

[Sunava Dutta] Once discussions conclude if this is not taken by HTML 5.0 we have no problem accommodating the request.
>
> --
> 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:46:03 UTC