W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Reason for aborting transactions

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 9 Feb 2011 17:54:31 -0800
Message-ID: <AANLkTi=Bt_1WiqgC2s1GJa_kJ-bTqt04EdeMjp1OYw+r@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: ben turner <bent.mozilla@gmail.com>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Wed, Feb 9, 2011 at 5:37 PM, ben turner <bent.mozilla@gmail.com> wrote:
>> > Normal exceptions have error messages that are not consistient across
>> > implementations and are not localized.  What's the difference?
>> These messages aren't part of any exception though, it's just some
>> property on a transaction object. (None of our DOM exceptions, IDB or
>> otherwise, have message properties btw, they're only converted to some
>> message if they make it to the error console).
>> > For stuff like internal errors, they seem especially important.
>> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
>> code?
> I think that'd be ideal, yes.  Since internal errors will be UA specific,
> string matching wouldn't be so bad there.
> If no one likes this idea, I'm happy hiding away the message in some
> webkitAbortMessage attribute so it's super clear it's just us who implements
> this.  (Speaking of which, maybe you guys should do that with getAll.)

We'll definitely put getAll under a vendor prefix once we drop the
"front door" prefix on .indexeddb.

I'm with Ben here. I'd prefer to hide the message away under a vendor
prefix (either now or once you drop the front door one) for now to
gather feedback on how it'll be used.

/ Jonas
Received on Thursday, 10 February 2011 01:55:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC