Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Tue, Feb 22, 2011 at 2:48 PM, Jeremy Orlow wrote: > On Sat, Feb 19, 2011 at 8:46 PM, Jonas Sicking wrote: >> >> On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow wrote: >> > If an exception is unhanded in an IDB event handler, we abort the >> > transaction. Should we continue firing the other handlers when this >> > happens, though? >> >> What do you mean by "other handlers"? The other handlers for that same >> event? If so, I would say we should so that we're sticking with the >> DOM Events spec. >> >> > And should preventDefault prevent the abort? >> >> preventDefault usually prevents the default action of the event. The >> abort isn't the default action, so I would say no. (It also seems a >> bit weird that calling preventDefault on a success event would prevent >> an abort). > > So if any of the event handlers doesn't catch an exception, there's no way > to keep the transaction from aborting? No. Your opportunity to prevent the abort is by catching the exception. Once you don't then that's equivalent to an explicit call to .abort(). Similarly, if you don't call .preventDefault() in an error handler, or do call .abort(), there is no way to later prevent the abort. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Sat, Feb 19, 2011 at 8:46 PM, Jonas Sicking wrote: > On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow wrote: > > If an exception is unhanded in an IDB event handler, we abort the > > transaction. Should we continue firing the other handlers when this > > happens, though? > > What do you mean by "other handlers"? The other handlers for that same > event? If so, I would say we should so that we're sticking with the > DOM Events spec. > > > And should preventDefault prevent the abort? > > preventDefault usually prevents the default action of the event. The > abort isn't the default action, so I would say no. (It also seems a > bit weird that calling preventDefault on a success event would prevent > an abort). > So if any of the event handlers doesn't catch an exception, there's no way to keep the transaction from aborting? J
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow wrote: > If an exception is unhanded in an IDB event handler, we abort the > transaction. Should we continue firing the other handlers when this > happens, though? What do you mean by "other handlers"? The other handlers for that same event? If so, I would say we should so that we're sticking with the DOM Events spec. > And should preventDefault prevent the abort? preventDefault usually prevents the default action of the event. The abort isn't the default action, so I would say no. (It also seems a bit weird that calling preventDefault on a success event would prevent an abort). / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
If an exception is unhanded in an IDB event handler, we abort the
transaction. Should we continue firing the other handlers when this
happens, though? And should preventDefault prevent the abort?
J
On Tue, Feb 15, 2011 at 11:52 AM, David Grogan wrote:
>
>
> On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking wrote:
>
>> On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow
>> wrote:
>> > On Mon, Feb 14, 2011 at 7:36 PM, David Grogan
>> wrote:
>> >>
>> >>
>> >> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow
>> wrote:
>> >>>
>> >>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking
>> wrote:
>>
>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
>> wrote:
>> > What's the current thinking in terms of events that we're firing?
>> I
>> > remember we talked about this a bit, but I don't remember the
>> > conclusion and
>> > I can't find it captured anywhere.
>> > Here's a brain dump of the requirements as I remember them:
>> > * Everything should have a source attribute.
>> > * Everything done in the context of a transaction should have a
>> > transaction
>> > attribute. (Probably even errors, which I believe is not the
>> current
>> > case.)
>> > * Only success events should have a result.
>> > * Only error events should have a code and a messageor should
>> they
>> > just
>> > have an error attribute which holds an IDBDatabaseError object?
>> (If
>> > it's
>> > the former, then do we even need an interface for IDBDatabaseError
>> to
>> > be
>> > defined?)
>> > * IIRC, Jonas suggested at some point that maybe there should be
>> > additional
>> > attributes beyond just the source and/or objects should link to
>> their
>> > parents. (The latter probably makes the most sense, right? If so,
>> > I'll bug
>> > it.)
>> > Is there anything I'm missing?
>> > As far as I can tell, this means we need 5 events: an IDBEvent
>> (with
>> > source)
>> > and then error with transaction, error without, success with, and
>> > success
>> > without. That seems kind of ugly though.
>> > Another possibility is that we could put a transaction attribute on
>> > IDBEvent
>> > that's null when there's no transaction. And then error and
>> success
>> > would
>> > have their own subclasses. To me, this sounds best.
>> > Thoughts?
>>
>> Actually, I was proposing something entirely different.
>>
>> IDBRequest should look like this:
>>
>> interface IDBRequest : EventTarget {
>> >>>
>> >>> For each, what do we do when it's not available? Throw exception?
>> >>> Return undefined? Null? Particularly in the errorCode case, it's
>> not
>> >>> clear to me what the right thing to do is.
>> >>>
>> >>
>> >> How do IDBVersionChangeEvent and its version attribute fit in to this
>> new
>> >> model? Should we add a nullable version attribute to IDBRequest and
>> let the
>> >> function handling a blocked event check event.target.version? Could we
>> add
>> >> a version attribute just to IDBVersionChangeRequest?
>> >
>> > Adding a "newVersion", "nextVersion", or something similar to
>> > IDBVersionChangeRequest seems like the best answer to me. Simply adding
>> > "version" to it seems kind of confusing though.
>>
>> Adding it to the request won't help as the versionchange event is
>> fired at other databases, not at the request.
>
>
> It's fired at the request if the version_change transaction is blocked
> because other connections to the database remain open after receiving
> versionchange events, but I see what you mean.
>
>
>> Adding it to the request
>> is also not needed since the new version isn't something that is the
>> result of the request, it's something you specify when creating the
>> request.
>>
>> I think we can leave IDBVersionChangeEvent as it is, it's an entirely
>> different beast from success/error.
>>
>
> I'm on board with this.
>
>
>> / Jonas
>>
>
>
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking wrote:
> On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow wrote:
> > On Mon, Feb 14, 2011 at 7:36 PM, David Grogan
> wrote:
> >>
> >>
> >> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow
> wrote:
> >>>
> >>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking
> wrote:
>
> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
> wrote:
> > What's the current thinking in terms of events that we're firing? I
> > remember we talked about this a bit, but I don't remember the
> > conclusion and
> > I can't find it captured anywhere.
> > Here's a brain dump of the requirements as I remember them:
> > * Everything should have a source attribute.
> > * Everything done in the context of a transaction should have a
> > transaction
> > attribute. (Probably even errors, which I believe is not the
> current
> > case.)
> > * Only success events should have a result.
> > * Only error events should have a code and a messageor should
> they
> > just
> > have an error attribute which holds an IDBDatabaseError object? (If
> > it's
> > the former, then do we even need an interface for IDBDatabaseError
> to
> > be
> > defined?)
> > * IIRC, Jonas suggested at some point that maybe there should be
> > additional
> > attributes beyond just the source and/or objects should link to
> their
> > parents. (The latter probably makes the most sense, right? If so,
> > I'll bug
> > it.)
> > Is there anything I'm missing?
> > As far as I can tell, this means we need 5 events: an IDBEvent (with
> > source)
> > and then error with transaction, error without, success with, and
> > success
> > without. That seems kind of ugly though.
> > Another possibility is that we could put a transaction attribute on
> > IDBEvent
> > that's null when there's no transaction. And then error and success
> > would
> > have their own subclasses. To me, this sounds best.
> > Thoughts?
>
> Actually, I was proposing something entirely different.
>
> IDBRequest should look like this:
>
> interface IDBRequest : EventTarget {
> >>>
> >>> For each, what do we do when it's not available? Throw exception?
> >>> Return undefined? Null? Particularly in the errorCode case, it's not
> >>> clear to me what the right thing to do is.
> >>>
> >>
> >> How do IDBVersionChangeEvent and its version attribute fit in to this
> new
> >> model? Should we add a nullable version attribute to IDBRequest and let
> the
> >> function handling a blocked event check event.target.version? Could we
> add
> >> a version attribute just to IDBVersionChangeRequest?
> >
> > Adding a "newVersion", "nextVersion", or something similar to
> > IDBVersionChangeRequest seems like the best answer to me. Simply adding
> > "version" to it seems kind of confusing though.
>
> Adding it to the request won't help as the versionchange event is
> fired at other databases, not at the request.
It's fired at the request if the version_change transaction is blocked
because other connections to the database remain open after receiving
versionchange events, but I see what you mean.
> Adding it to the request
> is also not needed since the new version isn't something that is the
> result of the request, it's something you specify when creating the
> request.
>
> I think we can leave IDBVersionChangeEvent as it is, it's an entirely
> different beast from success/error.
>
I'm on board with this.
> / Jonas
>
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow wrote:
> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking wrote:
>
>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
>> wrote:
>> > What's the current thinking in terms of events that we're firing? I
>> > remember we talked about this a bit, but I don't remember the conclusion
>> and
>> > I can't find it captured anywhere.
>> > Here's a brain dump of the requirements as I remember them:
>> > * Everything should have a source attribute.
>> > * Everything done in the context of a transaction should have a
>> transaction
>> > attribute. (Probably even errors, which I believe is not the current
>> case.)
>> > * Only success events should have a result.
>> > * Only error events should have a code and a messageor should they
>> just
>> > have an error attribute which holds an IDBDatabaseError object? (If
>> it's
>> > the former, then do we even need an interface for IDBDatabaseError to be
>> > defined?)
>> > * IIRC, Jonas suggested at some point that maybe there should be
>> additional
>> > attributes beyond just the source and/or objects should link to their
>> > parents. (The latter probably makes the most sense, right? If so, I'll
>> bug
>> > it.)
>> > Is there anything I'm missing?
>> > As far as I can tell, this means we need 5 events: an IDBEvent (with
>> source)
>> > and then error with transaction, error without, success with, and
>> success
>> > without. That seems kind of ugly though.
>> > Another possibility is that we could put a transaction attribute on
>> IDBEvent
>> > that's null when there's no transaction. And then error and success
>> would
>> > have their own subclasses. To me, this sounds best.
>> > Thoughts?
>>
>> Actually, I was proposing something entirely different.
>>
>> IDBRequest should look like this:
>>
>> interface IDBRequest : EventTarget {
>>
>
> For each, what do we do when it's not available? Throw exception? Return
> undefined? Null? Particularly in the errorCode case, it's not clear to me
> what the right thing to do is.
>
>
How do IDBVersionChangeEvent and its version attribute fit in to this new
model? Should we add a nullable version attribute to IDBRequest and let the
function handling a blocked event check event.target.version? Could we add
a version attribute just to IDBVersionChangeRequest?
attribute any result;
>>attribute unsigned long errorCode;
>>attribute DOMObject source;
>>attribute IDBTransaction transaction;
>>
>
>>const unsigned short LOADING = 1;
>>const unsigned short DONE = 2;
>>readonly attribute unsigned short readyState;
>>
>> attribute Function onsuccess;
>> attribute Function onerror;
>> };
>>
>> "success" and "error" events are plain Event objects, i.e. no
>> indexedDB-specific properties.
>>
>> The advantage of this is:
>> 1. Request objects are actually useful as representing the request.
>> Consumers of a request can check what the readystate is and either get
>> the .result or attach a event listener as appropriate. (As things
>> stand now you can't really rely on .readyState. The only thing it
>> tells you is if you got to the request too late or not. If you risk
>> getting there too late you better rewrite your code)
>> 2. Easier to implement a promises-style API on top of indexedDB.
>> 3. More similar to for example XMLHttpRequest
>>
>> The downside is:
>> 1. Have to use a bigger syntax to get to the result. "event.result"
>> vs. "event.target.result".
>>
>> / Jonas
>>
>
>
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow wrote:
> On Mon, Feb 14, 2011 at 7:36 PM, David Grogan wrote:
>>
>>
>> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow wrote:
>>>
>>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
wrote:
> What's the current thinking in terms of events that we're firing? I
> remember we talked about this a bit, but I don't remember the
> conclusion and
> I can't find it captured anywhere.
> Here's a brain dump of the requirements as I remember them:
> * Everything should have a source attribute.
> * Everything done in the context of a transaction should have a
> transaction
> attribute. (Probably even errors, which I believe is not the current
> case.)
> * Only success events should have a result.
> * Only error events should have a code and a messageor should they
> just
> have an error attribute which holds an IDBDatabaseError object? (If
> it's
> the former, then do we even need an interface for IDBDatabaseError to
> be
> defined?)
> * IIRC, Jonas suggested at some point that maybe there should be
> additional
> attributes beyond just the source and/or objects should link to their
> parents. (The latter probably makes the most sense, right? If so,
> I'll bug
> it.)
> Is there anything I'm missing?
> As far as I can tell, this means we need 5 events: an IDBEvent (with
> source)
> and then error with transaction, error without, success with, and
> success
> without. That seems kind of ugly though.
> Another possibility is that we could put a transaction attribute on
> IDBEvent
> that's null when there's no transaction. And then error and success
> would
> have their own subclasses. To me, this sounds best.
> Thoughts?
Actually, I was proposing something entirely different.
IDBRequest should look like this:
interface IDBRequest : EventTarget {
>>>
>>> For each, what do we do when it's not available? Throw exception?
>>> Return undefined? Null? Particularly in the errorCode case, it's not
>>> clear to me what the right thing to do is.
>>>
>>
>> How do IDBVersionChangeEvent and its version attribute fit in to this new
>> model? Should we add a nullable version attribute to IDBRequest and let the
>> function handling a blocked event check event.target.version? Could we add
>> a version attribute just to IDBVersionChangeRequest?
>
> Adding a "newVersion", "nextVersion", or something similar to
> IDBVersionChangeRequest seems like the best answer to me. Simply adding
> "version" to it seems kind of confusing though.
Adding it to the request won't help as the versionchange event is
fired at other databases, not at the request. Adding it to the request
is also not needed since the new version isn't something that is the
result of the request, it's something you specify when creating the
request.
I think we can leave IDBVersionChangeEvent as it is, it's an entirely
different beast from success/error.
/ Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan wrote:
>
>
> On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow wrote:
>
>> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking wrote:
>>
>>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
>>> wrote:
>>> > What's the current thinking in terms of events that we're firing? I
>>> > remember we talked about this a bit, but I don't remember the
>>> conclusion and
>>> > I can't find it captured anywhere.
>>> > Here's a brain dump of the requirements as I remember them:
>>> > * Everything should have a source attribute.
>>> > * Everything done in the context of a transaction should have a
>>> transaction
>>> > attribute. (Probably even errors, which I believe is not the current
>>> case.)
>>> > * Only success events should have a result.
>>> > * Only error events should have a code and a messageor should they
>>> just
>>> > have an error attribute which holds an IDBDatabaseError object? (If
>>> it's
>>> > the former, then do we even need an interface for IDBDatabaseError to
>>> be
>>> > defined?)
>>> > * IIRC, Jonas suggested at some point that maybe there should be
>>> additional
>>> > attributes beyond just the source and/or objects should link to their
>>> > parents. (The latter probably makes the most sense, right? If so,
>>> I'll bug
>>> > it.)
>>> > Is there anything I'm missing?
>>> > As far as I can tell, this means we need 5 events: an IDBEvent (with
>>> source)
>>> > and then error with transaction, error without, success with, and
>>> success
>>> > without. That seems kind of ugly though.
>>> > Another possibility is that we could put a transaction attribute on
>>> IDBEvent
>>> > that's null when there's no transaction. And then error and success
>>> would
>>> > have their own subclasses. To me, this sounds best.
>>> > Thoughts?
>>>
>>> Actually, I was proposing something entirely different.
>>>
>>> IDBRequest should look like this:
>>>
>>> interface IDBRequest : EventTarget {
>>>
>>
>> For each, what do we do when it's not available? Throw exception? Return
>> undefined? Null? Particularly in the errorCode case, it's not clear to me
>> what the right thing to do is.
>>
>>
>
> How do IDBVersionChangeEvent and its version attribute fit in to this new
> model? Should we add a nullable version attribute to IDBRequest and let the
> function handling a blocked event check event.target.version? Could we add
> a version attribute just to IDBVersionChangeRequest?
>
Adding a "newVersion", "nextVersion", or something similar to
IDBVersionChangeRequest seems like the best answer to me. Simply adding
"version" to it seems kind of confusing though.
J
> attribute any result;
>>>attribute unsigned long errorCode;
>>>attribute DOMObject source;
>>>attribute IDBTransaction transaction;
>>>
>>
>>>const unsigned short LOADING = 1;
>>>const unsigned short DONE = 2;
>>>readonly attribute unsigned short readyState;
>>>
>>> attribute Function onsuccess;
>>> attribute Function onerror;
>>> };
>>>
>>> "success" and "error" events are plain Event objects, i.e. no
>>> indexedDB-specific properties.
>>>
>>> The advantage of this is:
>>> 1. Request objects are actually useful as representing the request.
>>> Consumers of a request can check what the readystate is and either get
>>> the .result or attach a event listener as appropriate. (As things
>>> stand now you can't really rely on .readyState. The only thing it
>>> tells you is if you got to the request too late or not. If you risk
>>> getting there too late you better rewrite your code)
>>> 2. Easier to implement a promises-style API on top of indexedDB.
>>> 3. More similar to for example XMLHttpRequest
>>>
>>> The downside is:
>>> 1. Have to use a bigger syntax to get to the result. "event.result"
>>> vs. "event.target.result".
>>>
>>> / Jonas
>>>
>>
>>
>
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 12:41 PM, Simon Pieters wrote: > On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking wrote: > >> In many of these cases other things than programming errors are likely >> the cause of the error. In most of what you are listing network errors >> are likely the most common source of errors. > > Yeah. (I got the list by searching for "named error" in the spec, which > matched a bunch of stuff that fires error events, but the list is very > likely not exhaustive.) > > >> Note again that the IndexedDB errors we are talking about here are >> semantically very similar to exceptions. The only reason we're not >> making them exceptions is that we can't since exceptions would require >> synchronous IO. So I would argue that consistency with exceptions is >> more important that consistency with much of what you list above. > > OK. > > >> That said, maybe we should fire window.onerror for many of the things >> that you list above. > > Could you file a bug to that effect? I filed two bugs, one for workers in particular, and a general one for investigating making window.onerror more useful. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12068 >> I'll repeat my question which you left >> unanswered: >> >> What is the use case for window.onerror that you had in mind which >> would require that we *don't* fire window.onerror for IndexedDB >> errors? > > No use case for not doing it. I'm fine with doing it if there's a use case > that warrants doing it, and we can keep the platform consistent with errors > elsewhere. I think the usecase for window.onerror is a choke point for catching errors that arise in the page. At the very least programming errors. The choke point can be used to report back the error to the server as an error logging mechanism. It can possibly also be used for reporting errors directly to the user in the case the user is also the website author. However it seems like developer tools support that usecase better today. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking wrote: In many of these cases other things than programming errors are likely the cause of the error. In most of what you are listing network errors are likely the most common source of errors. Yeah. (I got the list by searching for "named error" in the spec, which matched a bunch of stuff that fires error events, but the list is very likely not exhaustive.) Note again that the IndexedDB errors we are talking about here are semantically very similar to exceptions. The only reason we're not making them exceptions is that we can't since exceptions would require synchronous IO. So I would argue that consistency with exceptions is more important that consistency with much of what you list above. OK. That said, maybe we should fire window.onerror for many of the things that you list above. Could you file a bug to that effect? I'll repeat my question which you left unanswered: What is the use case for window.onerror that you had in mind which would require that we *don't* fire window.onerror for IndexedDB errors? No use case for not doing it. I'm fine with doing it if there's a use case that warrants doing it, and we can keep the platform consistent with errors elsewhere. cheers -- Simon Pieters Opera Software
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 12:06 AM, Simon Pieters wrote: > On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking wrote: > >> On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters wrote: >>> >>> On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking >>> wrote: >>> On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: > > Just to confirm, we don't want the events to propagate to the window > itself, > right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request->transaction->database. This goes for both "success" and "error" events. However "success" doesn't bubble so "normal" event handlers doesn't fire on the transaction or database for "success". But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For "abort" events the propagation path is just transaction->database since the target of "abort" events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an "error" event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing "error" handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. >>> >>> Hmm. I'm not sure what to think of IndexedDB using window.onerror. >>> window.onerror is used for catching JS syntax errors and uncaught >>> exceptions >>> in scripts. Also, window.onerror is invoked directly without firing an >>> actual event. >> >> Not just syntax errors. At least in firefox it also fires for uncaught >> exceptions. > > That's what I said. :-) Oops, my bad :-) >> So basically we fire all javascript errors which goes unhandled by the >> page (there is no way to handle syntax errors so they always goes >> unhandled). That is very much the case here, however since the error >> reporting must be asynchronous we report it using a event rather than >> an exception. >> >>> What's the use case for firing an error event on window for IndexedDB? >> >> What is the use case for error events? I've always thought of it as a >> choke point where pages can catch JS errors and either display to the >> user or report back to the server for debugging. If that is the case >> then this is just another case where errors can arise. >> >> Do you have another use case in mind? > > There are lots of errors in the Web platform that are not reported to > window.onerror: > > >
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking wrote: On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: Just to confirm, we don't want the events to propagate to the window itself, right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request->transaction->database. This goes for both "success" and "error" events. However "success" doesn't bubble so "normal" event handlers doesn't fire on the transaction or database for "success". But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For "abort" events the propagation path is just transaction->database since the target of "abort" events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an "error" event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing "error" handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. Hmm. I'm not sure what to think of IndexedDB using window.onerror. window.onerror is used for catching JS syntax errors and uncaught exceptions in scripts. Also, window.onerror is invoked directly without firing an actual event. Not just syntax errors. At least in firefox it also fires for uncaught exceptions. That's what I said. :-) So basically we fire all javascript errors which goes unhandled by the page (there is no way to handle syntax errors so they always goes unhandled). That is very much the case here, however since the error reporting must be asynchronous we report it using a event rather than an exception. What's the use case for firing an error event on window for IndexedDB? What is the use case for error events? I've always thought of it as a choke point where pages can catch JS errors and either display to the user or report back to the server for debugging. If that is the case then this is just another case where errors can arise. Do you have another use case in mind? There are lots of errors in the Web platform that are not reported to window.onerror:
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Fri, Feb 11, 2011 at 11:38 AM, Jonas Sicking wrote: > On Fri, Feb 11, 2011 at 11:30 AM, ben turner > wrote: > > It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for > > getting errorCode *and* result before readyState is set to DONE. > > > > And now that I think about it I think I like that best. If we returned > > NO_ERR from errorCode before DONE then it seems to imply that the > > request succeeded when the reality is we don't yet know. Checking > > errorCode before DONE is most likely a bug in the page script just as > > calling result before DONE, so I'm happy with throwing here. > > > > Sound ok? > > Ah, I thought that's what you were saying in your previous email :-) > > I.e. throw when it's almost surely a bug in the script (reading too > early), and return 0/undefined once there is a result of some sort. > > Sounds ok to me. > Sounds good to me. J
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Fri, Feb 11, 2011 at 11:30 AM, ben turner wrote: > It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for > getting errorCode *and* result before readyState is set to DONE. > > And now that I think about it I think I like that best. If we returned > NO_ERR from errorCode before DONE then it seems to imply that the > request succeeded when the reality is we don't yet know. Checking > errorCode before DONE is most likely a bug in the page script just as > calling result before DONE, so I'm happy with throwing here. > > Sound ok? Ah, I thought that's what you were saying in your previous email :-) I.e. throw when it's almost surely a bug in the script (reading too early), and return 0/undefined once there is a result of some sort. Sounds ok to me. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for getting errorCode *and* result before readyState is set to DONE. And now that I think about it I think I like that best. If we returned NO_ERR from errorCode before DONE then it seems to imply that the request succeeded when the reality is we don't yet know. Checking errorCode before DONE is most likely a bug in the page script just as calling result before DONE, so I'm happy with throwing here. Sound ok? -Ben
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Fri, Feb 11, 2011 at 11:16 AM, Jeremy Orlow wrote: > On Thu, Feb 10, 2011 at 7:06 PM, ben turner wrote: >> >> > I think generally avoiding throwing exceptions is a good thing. So for >> > .errorCode I would say returning unidentified or 0 is the way to go. >> >> I would say we should add a code to IDBDatabaseException, NO_ERR = 0. >> Or else indicate somehow that 0 is reserved for "no exception". Then >> return that from errorCode. >> >> > But it does seem like a >> > pretty bad bug if you do access these properties before having a >> > result. So maybe exception is in fact better here. >> >> Definitely agreed. People will want to know that they're checking a >> result too early. > > Is this the behavior shipping in ff4? I don't recall, but looking at the code it looks that way. Ben can hopefully confirm? / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Feb 10, 2011 at 7:06 PM, ben turner wrote: > > I think generally avoiding throwing exceptions is a good thing. So for > > .errorCode I would say returning unidentified or 0 is the way to go. > > I would say we should add a code to IDBDatabaseException, NO_ERR = 0. > Or else indicate somehow that 0 is reserved for "no exception". Then > return that from errorCode. > > > But it does seem like a > > pretty bad bug if you do access these properties before having a > > result. So maybe exception is in fact better here. > > Definitely agreed. People will want to know that they're checking a > result too early. > Is this the behavior shipping in ff4? J
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> I think generally avoiding throwing exceptions is a good thing. So for > .errorCode I would say returning unidentified or 0 is the way to go. I would say we should add a code to IDBDatabaseException, NO_ERR = 0. Or else indicate somehow that 0 is reserved for "no exception". Then return that from errorCode. > But it does seem like a > pretty bad bug if you do access these properties before having a > result. So maybe exception is in fact better here. Definitely agreed. People will want to know that they're checking a result too early. -Ben
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow wrote:
> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking wrote:
>>
>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
>> wrote:
>> > What's the current thinking in terms of events that we're firing? I
>> > remember we talked about this a bit, but I don't remember the conclusion
>> > and
>> > I can't find it captured anywhere.
>> > Here's a brain dump of the requirements as I remember them:
>> > * Everything should have a source attribute.
>> > * Everything done in the context of a transaction should have a
>> > transaction
>> > attribute. (Probably even errors, which I believe is not the current
>> > case.)
>> > * Only success events should have a result.
>> > * Only error events should have a code and a messageor should they
>> > just
>> > have an error attribute which holds an IDBDatabaseError object? (If
>> > it's
>> > the former, then do we even need an interface for IDBDatabaseError to be
>> > defined?)
>> > * IIRC, Jonas suggested at some point that maybe there should be
>> > additional
>> > attributes beyond just the source and/or objects should link to their
>> > parents. (The latter probably makes the most sense, right? If so, I'll
>> > bug
>> > it.)
>> > Is there anything I'm missing?
>> > As far as I can tell, this means we need 5 events: an IDBEvent (with
>> > source)
>> > and then error with transaction, error without, success with, and
>> > success
>> > without. That seems kind of ugly though.
>> > Another possibility is that we could put a transaction attribute on
>> > IDBEvent
>> > that's null when there's no transaction. And then error and success
>> > would
>> > have their own subclasses. To me, this sounds best.
>> > Thoughts?
>>
>> Actually, I was proposing something entirely different.
>>
>> IDBRequest should look like this:
>>
>> interface IDBRequest : EventTarget {
>
> For each, what do we do when it's not available? Throw exception? Return
> undefined? Null? Particularly in the errorCode case, it's not clear to me
> what the right thing to do is.
So there are two situations when the result is "not available".
* After success/error has fired, but the "other" property is accessed.
* Before either success or result has fired.
I think generally avoiding throwing exceptions is a good thing. So for
.errorCode I would say returning unidentified or 0 is the way to go.
The latter is possibly more consistent with how other DOM APIs behave
since they tend to return a specific type. The former might be more
javascripty. I don't think it matters much as long as people can do
if (!req.errorCode) {
...assume success...
}
In the latter case it might be consistent with the rest of indexedDB
to throw NOT_ALLOWED_ERR. But going with "don't throw errors", it
might be better to returning 0/undefined. But it does seem like a
pretty bad bug if you do access these properties before having a
result. So maybe exception is in fact better here.
/ Jonas
>>
>> attribute any result;
>> attribute unsigned long errorCode;
>> attribute DOMObject source;
>> attribute IDBTransaction transaction;
>>
>> const unsigned short LOADING = 1;
>> const unsigned short DONE = 2;
>> readonly attribute unsigned short readyState;
>>
>> attribute Function onsuccess;
>> attribute Function onerror;
>> };
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking wrote:
> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow
> wrote:
> > What's the current thinking in terms of events that we're firing? I
> > remember we talked about this a bit, but I don't remember the conclusion
> and
> > I can't find it captured anywhere.
> > Here's a brain dump of the requirements as I remember them:
> > * Everything should have a source attribute.
> > * Everything done in the context of a transaction should have a
> transaction
> > attribute. (Probably even errors, which I believe is not the current
> case.)
> > * Only success events should have a result.
> > * Only error events should have a code and a messageor should they
> just
> > have an error attribute which holds an IDBDatabaseError object? (If it's
> > the former, then do we even need an interface for IDBDatabaseError to be
> > defined?)
> > * IIRC, Jonas suggested at some point that maybe there should be
> additional
> > attributes beyond just the source and/or objects should link to their
> > parents. (The latter probably makes the most sense, right? If so, I'll
> bug
> > it.)
> > Is there anything I'm missing?
> > As far as I can tell, this means we need 5 events: an IDBEvent (with
> source)
> > and then error with transaction, error without, success with, and success
> > without. That seems kind of ugly though.
> > Another possibility is that we could put a transaction attribute on
> IDBEvent
> > that's null when there's no transaction. And then error and success
> would
> > have their own subclasses. To me, this sounds best.
> > Thoughts?
>
> Actually, I was proposing something entirely different.
>
> IDBRequest should look like this:
>
> interface IDBRequest : EventTarget {
>
For each, what do we do when it's not available? Throw exception? Return
undefined? Null? Particularly in the errorCode case, it's not clear to me
what the right thing to do is.
>attribute any result;
>attribute unsigned long errorCode;
>attribute DOMObject source;
>attribute IDBTransaction transaction;
>
>const unsigned short LOADING = 1;
>const unsigned short DONE = 2;
>readonly attribute unsigned short readyState;
>
> attribute Function onsuccess;
> attribute Function onerror;
> };
>
> "success" and "error" events are plain Event objects, i.e. no
> indexedDB-specific properties.
>
> The advantage of this is:
> 1. Request objects are actually useful as representing the request.
> Consumers of a request can check what the readystate is and either get
> the .result or attach a event listener as appropriate. (As things
> stand now you can't really rely on .readyState. The only thing it
> tells you is if you got to the request too late or not. If you risk
> getting there too late you better rewrite your code)
> 2. Easier to implement a promises-style API on top of indexedDB.
> 3. More similar to for example XMLHttpRequest
>
> The downside is:
> 1. Have to use a bigger syntax to get to the result. "event.result"
> vs. "event.target.result".
>
> / Jonas
>
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters wrote: > On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking wrote: > >> On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: >>> >>> Just to confirm, we don't want the events to propagate to the window >>> itself, >>> right? >> >> Correct. Sort of. Here's what we did in gecko: >> >> The event propagation path is request->transaction->database. This >> goes for both "success" and "error" events. However "success" doesn't >> bubble so "normal" event handlers doesn't fire on the transaction or >> database for "success". But if you really want you can attach a >> capturing listener using .addEventListener and listen to them there. >> This matches events fired on nodes. >> >> For "abort" events the propagation path is just transaction->database >> since the target of "abort" events is the transaction. >> >> So far this matches what you said. >> >> However, we also wanted to integrate the window.onerror feature in >> HTML5. So after we've fired an "error" event, if .preventDefault() was >> never called on the event, we fire an error event on the window (can't >> remember if this happens before or after we abort the transaction). >> This is a separate event, which for example means that even if you >> attach a capturing "error" handler on window, you won't see any events >> unless an error really went unhandled. And you also can't call >> .preventDefault on the error event fired on the window in order to >> prevent the transaction from being aborted. It's purely there for >> error reporting and distinctly different from the event propagating to >> the window. > > Hmm. I'm not sure what to think of IndexedDB using window.onerror. > window.onerror is used for catching JS syntax errors and uncaught exceptions > in scripts. Also, window.onerror is invoked directly without firing an > actual event. Not just syntax errors. At least in firefox it also fires for uncaught exceptions. So basically we fire all javascript errors which goes unhandled by the page (there is no way to handle syntax errors so they always goes unhandled). That is very much the case here, however since the error reporting must be asynchronous we report it using a event rather than an exception. > What's the use case for firing an error event on window for IndexedDB? What is the use case for error events? I've always thought of it as a choke point where pages can catch JS errors and either display to the user or report back to the server for debugging. If that is the case then this is just another case where errors can arise. Do you have another use case in mind? >> This is similar to how "error" events are handled in workers. > > Not really. Workers have their own onerror handler in the worker script > itself, and if the error is still "not handled", an error event is fired on > the worker object, but it stops there; an error event is never fired on > window. That's not the case in the gecko implementation. But I see the spec doesn't call for this yet. I'll file a bug on the spec. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: Just to confirm, we don't want the events to propagate to the window itself, right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request->transaction->database. This goes for both "success" and "error" events. However "success" doesn't bubble so "normal" event handlers doesn't fire on the transaction or database for "success". But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For "abort" events the propagation path is just transaction->database since the target of "abort" events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an "error" event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing "error" handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. Hmm. I'm not sure what to think of IndexedDB using window.onerror. window.onerror is used for catching JS syntax errors and uncaught exceptions in scripts. Also, window.onerror is invoked directly without firing an actual event. What's the use case for firing an error event on window for IndexedDB? This is similar to how "error" events are handled in workers. Not really. Workers have their own onerror handler in the worker script itself, and if the error is still "not handled", an error event is fired on the worker object, but it stops there; an error event is never fired on window. -- Simon Pieters Opera Software
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Wed, Feb 2, 2011 at 3:21 PM, Jonas Sicking wrote: > On Wed, Feb 2, 2011 at 3:19 PM, Jeremy Orlow wrote: > > I don't know much about window.onerror (I'm finding out what the story is > in > > WebKit), but overall sounds fine to me. > > What about complete events? Should we make those non-bubbling as well? > > Good question. I think so yeah. Don't have a strong opinion either way. > > The only argument I can think of that if it bubbles then we might want > to add .oncomplete on IDBDatabase, which would be somewhat confusing. > That was my same line of thought. J
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Wed, Feb 2, 2011 at 3:19 PM, Jeremy Orlow wrote: > I don't know much about window.onerror (I'm finding out what the story is in > WebKit), but overall sounds fine to me. > What about complete events? Should we make those non-bubbling as well? Good question. I think so yeah. Don't have a strong opinion either way. The only argument I can think of that if it bubbles then we might want to add .oncomplete on IDBDatabase, which would be somewhat confusing. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
I don't know much about window.onerror (I'm finding out what the story is in WebKit), but overall sounds fine to me. What about complete events? Should we make those non-bubbling as well? J On Wed, Feb 2, 2011 at 2:28 PM, Jonas Sicking wrote: > On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: > > Just to confirm, we don't want the events to propagate to the window > itself, > > right? > > Correct. Sort of. Here's what we did in gecko: > > The event propagation path is request->transaction->database. This > goes for both "success" and "error" events. However "success" doesn't > bubble so "normal" event handlers doesn't fire on the transaction or > database for "success". But if you really want you can attach a > capturing listener using .addEventListener and listen to them there. > This matches events fired on nodes. > > For "abort" events the propagation path is just transaction->database > since the target of "abort" events is the transaction. > > So far this matches what you said. > > However, we also wanted to integrate the window.onerror feature in > HTML5. So after we've fired an "error" event, if .preventDefault() was > never called on the event, we fire an error event on the window (can't > remember if this happens before or after we abort the transaction). > This is a separate event, which for example means that even if you > attach a capturing "error" handler on window, you won't see any events > unless an error really went unhandled. And you also can't call > .preventDefault on the error event fired on the window in order to > prevent the transaction from being aborted. It's purely there for > error reporting and distinctly different from the event propagating to > the window. > > This is similar to how "error" events are handled in workers. > > (I think that so far webkit hasn't implemented the window.onerror > feature yet, so you probably don't want to fire the separate error > event on the window until that has been implemented). > > I hope this makes sense and sounds like a good idea? > > / Jonas >
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow wrote: > Just to confirm, we don't want the events to propagate to the window itself, > right? Correct. Sort of. Here's what we did in gecko: The event propagation path is request->transaction->database. This goes for both "success" and "error" events. However "success" doesn't bubble so "normal" event handlers doesn't fire on the transaction or database for "success". But if you really want you can attach a capturing listener using .addEventListener and listen to them there. This matches events fired on nodes. For "abort" events the propagation path is just transaction->database since the target of "abort" events is the transaction. So far this matches what you said. However, we also wanted to integrate the window.onerror feature in HTML5. So after we've fired an "error" event, if .preventDefault() was never called on the event, we fire an error event on the window (can't remember if this happens before or after we abort the transaction). This is a separate event, which for example means that even if you attach a capturing "error" handler on window, you won't see any events unless an error really went unhandled. And you also can't call .preventDefault on the error event fired on the window in order to prevent the transaction from being aborted. It's purely there for error reporting and distinctly different from the event propagating to the window. This is similar to how "error" events are handled in workers. (I think that so far webkit hasn't implemented the window.onerror feature yet, so you probably don't want to fire the separate error event on the window until that has been implemented). I hope this makes sense and sounds like a good idea? / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
Just to confirm, we don't want the events to propagate to the window itself, right? On Fri, Nov 19, 2010 at 3:44 AM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348 > > Summary: [IndexedDB] Overhaul of the event model > Product: WebAppsWG > Version: unspecified > Platform: PC >OS/Version: All >Status: NEW > Severity: normal > Priority: P2 > Component: Indexed Database API >AssignedTo: dave.n...@w3.org >ReportedBy: jor...@chromium.org > QAContact: member-webapi-...@w3.org >CC: m...@w3.org, public-webapps@w3.org > > > We talked about this for a while at TPAC. Here's what I think we agreed > upon > at the time: > > * All events should propagate from the IDBRequest to the IDBTransaction to > the > IDBDatabase. > > * For error events, preventDefault must be called in order to avoid a > transaction aborting. (When you use onerror, you'd of course use false to > do > so.) > > * If you throw within an event handler, the transaction will abort. (Catch > errors that you don't want to implicitly abort the transaction.) > > * The success event will be non-bubbling (because having onsuccess on > IDBTransaction and IDBDatabase would be confusing). > > * The error event should be added to IDBTransaction and IDBDatabase and > should > bubble. > > * createObjectStore should remain sync and simply abort the transaction on > errors (which are pretty much constrained to quota and internal errors). > > * createIndex is the same, except that indexes with a uniqueness constraint > and > existing data that doesn't satisfy it will present another (and more > common) > case that'll cause the transaction to abort. The spec should have a red > note > that reminds people of this. > > -- > Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. > >
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
>> Agreed. My only aside would be that for API design, it’s usually not a good >> idea to listen to web developers, but to someone who has experience with >> designing DB APIs (= not me, but possibly anyone of you or anyone at >> Mozilla, MS, Google). > It sounds like you are saying we aren't listening to people who have designed > database APIs. We certainly have (and have borrowed from models of existing > APIs for other databases too). I hope I was and am sounding constructive, I really appreciate the hard work that went into IndexedDB and am trying to understand the design rationales. So far I have used APIs for JDBC, WebDatabase, RDF, and CouchDB. And they all seemed similar in the patterns they used (how functionality was invoked etc.). I was wondering why IndexedDB was so different. Until now, I have only seen events in bus-like constructs (Node.js event emitters, DOM events for DOM elements, custom DOM events for a complete web page, etc.). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On 1/28/2011 1:07 AM, Axel Rauschmayer wrote: Agreed. My only aside would be that for API design, it’s usually not a good idea to listen to web developers, but to someone who has experience with designing DB APIs (= not me, but possibly anyone of you or anyone at Mozilla, MS, Google). It sounds like you are saying we aren't listening to people who have designed database APIs. We certainly have (and have borrowed from models of existing APIs for other databases too). It seems a bit disingenuous to not listen to feedback of web developers who are the primary target audience of this API. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On 1/28/2011 1:15 AM, Axel Rauschmayer wrote: All API invocations that I have seen relied on run-to-completion semantics and add a listener after the initial invocation. These now have to check the flag? No, all that works just like it did before. The flag just allows for some additional flexibility for authors. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> Also note that the reason that your suggestion removes the need for > readyState is that your proposal decides to drop support for the > use-case that readyState aims to help solve. I.e. the ability to > register additional event handlers sometime after the request is > created. All API invocations that I have seen relied on run-to-completion semantics and add a listener after the initial invocation. These now have to check the flag? Note that one can create the event emitter (and register handlers) before invoking an operation. > >> Then IDBRequest would be more like an event, right? It would be sent to the >> onsuccess and onerror event handlers. > > I don't understand what you mean here. But in the current model (both > the one that's in the spec right now, and the one that I'm proposing) > we're using real DOM-Events. Can't really get more "like events" than > that? Right, I’m sorry. I was confused, because IDBRequest plays double duty. To me an event is something that is created at the event emitter and directly sent to event handlers, without exposing it inbetween. That is too narror and IDBRequest is indeed an event. -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> I'm still not convinced this use case is necessary either, but we've already > argued that to death, so let's not start up again. Agreed. My only aside would be that for API design, it’s usually not a good idea to listen to web developers, but to someone who has experience with designing DB APIs (= not me, but possibly anyone of you or anyone at Mozilla, MS, Google). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Jan 27, 2011 at 8:20 PM, ben turner wrote: >>> Lastly, let's say you're doing cursor.continue() on an index cursor, how can >>> you get a handle to the objectStore? I believe you can't. > > We gave IDBCursor a source property too, that either points to the > objectStore or index depending on who called openCursor. Ah, this is a better solution I agree. And makes sense to not return a request from continue() as to avoid people thinking that they have to re-register a listener. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
>> Lastly, let's say you're doing cursor.continue() on an index cursor, how can >> you get a handle to the objectStore? I believe you can't. We gave IDBCursor a source property too, that either points to the objectStore or index depending on who called openCursor. -Ben
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> The call to .continue() returns a IDBRequest (same one as was > originally returned from .openCursor()). No... continue() returns void as currently spec'd and implemented in FF. -Ben
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Jan 27, 2011 at 7:16 PM, Jeremy Orlow wrote: > On Thu, Jan 27, 2011 at 5:48 PM, Jonas Sicking wrote: >> >> On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer >> wrote: >> > I am really sorry to bring this up again, but: Why not separate >> > concerns? Why not separate input data and output data? >> > >> > If onsuccess and onerror were handed in as an input parameters, would >> > there be any need for readyState, LOADING, and DONE? >> >> We decided a long long time ago, based on input from web developers, >> to use DOM-Events as notification mechanism. We went through the same >> thing in the FileReader API where I initially suggested using a >> different type of callback, but got the feedback that developers >> preferred to use DOM-Events. >> >> Also note that the reason that your suggestion removes the need for >> readyState is that your proposal decides to drop support for the >> use-case that readyState aims to help solve. I.e. the ability to >> register additional event handlers sometime after the request is >> created. > > I'm still not convinced this use case is necessary either, but we've already > argued that to death, so let's not start up again. > Is all of this what was implemented in FF4b9? If so, I'll do it in > Chromium, though the event.target syntax really is kind of horrible. Yup, this is all in FF4b (can't remember if it was in 9, but it is in 10 which is the latest released one). > Lastly, let's say you're doing cursor.continue() on an index cursor, how can > you get a handle to the objectStore? I believe you can't. Should we add in > something for that? (Most likely give the index a link to its object store? > And maybe even give a cursor a link back up as well?) Yup, we added a .objectStore property on IDBIndex. The call to .continue() returns a IDBRequest (same one as was originally returned from .openCursor()). This IDBRequest has a .source which is the IDBIndex object. Is that enough from the cursor to the index? I don't feel strongly. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Jan 27, 2011 at 5:48 PM, Jonas Sicking wrote: > On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer > wrote: > > I am really sorry to bring this up again, but: Why not separate concerns? > Why not separate input data and output data? > > > > If onsuccess and onerror were handed in as an input parameters, would > there be any need for readyState, LOADING, and DONE? > > We decided a long long time ago, based on input from web developers, > to use DOM-Events as notification mechanism. We went through the same > thing in the FileReader API where I initially suggested using a > different type of callback, but got the feedback that developers > preferred to use DOM-Events. > > Also note that the reason that your suggestion removes the need for > readyState is that your proposal decides to drop support for the > use-case that readyState aims to help solve. I.e. the ability to > register additional event handlers sometime after the request is > created. > I'm still not convinced this use case is necessary either, but we've already argued that to death, so let's not start up again. Is all of this what was implemented in FF4b9? If so, I'll do it in Chromium, though the event.target syntax really is kind of horrible. Lastly, let's say you're doing cursor.continue() on an index cursor, how can you get a handle to the objectStore? I believe you can't. Should we add in something for that? (Most likely give the index a link to its object store? And maybe even give a cursor a link back up as well?) J > > Then IDBRequest would be more like an event, right? It would be sent to > the onsuccess and onerror event handlers. > > I don't understand what you mean here. But in the current model (both > the one that's in the spec right now, and the one that I'm proposing) > we're using real DOM-Events. Can't really get more "like events" than > that? > > / Jonas >
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer wrote: > I am really sorry to bring this up again, but: Why not separate concerns? Why > not separate input data and output data? > > If onsuccess and onerror were handed in as an input parameters, would there > be any need for readyState, LOADING, and DONE? We decided a long long time ago, based on input from web developers, to use DOM-Events as notification mechanism. We went through the same thing in the FileReader API where I initially suggested using a different type of callback, but got the feedback that developers preferred to use DOM-Events. Also note that the reason that your suggestion removes the need for readyState is that your proposal decides to drop support for the use-case that readyState aims to help solve. I.e. the ability to register additional event handlers sometime after the request is created. > Then IDBRequest would be more like an event, right? It would be sent to the > onsuccess and onerror event handlers. I don't understand what you mean here. But in the current model (both the one that's in the spec right now, and the one that I'm proposing) we're using real DOM-Events. Can't really get more "like events" than that? / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
I am really sorry to bring this up again, but: Why not separate concerns? Why
not separate input data and output data?
If onsuccess and onerror were handed in as an input parameters, would there be
any need for readyState, LOADING, and DONE? Then IDBRequest would be more like
an event, right? It would be sent to the onsuccess and onerror event handlers.
> Actually, I was proposing something entirely different.
>
> IDBRequest should look like this:
>
> interface IDBRequest : EventTarget {
>attribute any result;
>attribute unsigned long errorCode;
>attribute DOMObject source;
>attribute IDBTransaction transaction;
>
>const unsigned short LOADING = 1;
>const unsigned short DONE = 2;
>readonly attribute unsigned short readyState;
>
> attribute Function onsuccess;
> attribute Function onerror;
> };
>
> "success" and "error" events are plain Event objects, i.e. no
> indexedDB-specific properties.
>
> The advantage of this is:
> 1. Request objects are actually useful as representing the request.
> Consumers of a request can check what the readystate is and either get
> the .result or attach a event listener as appropriate. (As things
> stand now you can't really rely on .readyState. The only thing it
> tells you is if you got to the request too late or not. If you risk
> getting there too late you better rewrite your code)
> 2. Easier to implement a promises-style API on top of indexedDB.
> 3. More similar to for example XMLHttpRequest
>
> The downside is:
> 1. Have to use a bigger syntax to get to the result. "event.result"
> vs. "event.target.result".
>
> / Jonas
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow wrote:
> What's the current thinking in terms of events that we're firing? I
> remember we talked about this a bit, but I don't remember the conclusion and
> I can't find it captured anywhere.
> Here's a brain dump of the requirements as I remember them:
> * Everything should have a source attribute.
> * Everything done in the context of a transaction should have a transaction
> attribute. (Probably even errors, which I believe is not the current case.)
> * Only success events should have a result.
> * Only error events should have a code and a messageor should they just
> have an error attribute which holds an IDBDatabaseError object? (If it's
> the former, then do we even need an interface for IDBDatabaseError to be
> defined?)
> * IIRC, Jonas suggested at some point that maybe there should be additional
> attributes beyond just the source and/or objects should link to their
> parents. (The latter probably makes the most sense, right? If so, I'll bug
> it.)
> Is there anything I'm missing?
> As far as I can tell, this means we need 5 events: an IDBEvent (with source)
> and then error with transaction, error without, success with, and success
> without. That seems kind of ugly though.
> Another possibility is that we could put a transaction attribute on IDBEvent
> that's null when there's no transaction. And then error and success would
> have their own subclasses. To me, this sounds best.
> Thoughts?
Actually, I was proposing something entirely different.
IDBRequest should look like this:
interface IDBRequest : EventTarget {
attribute any result;
attribute unsigned long errorCode;
attribute DOMObject source;
attribute IDBTransaction transaction;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
attribute Function onsuccess;
attribute Function onerror;
};
"success" and "error" events are plain Event objects, i.e. no
indexedDB-specific properties.
The advantage of this is:
1. Request objects are actually useful as representing the request.
Consumers of a request can check what the readystate is and either get
the .result or attach a event listener as appropriate. (As things
stand now you can't really rely on .readyState. The only thing it
tells you is if you got to the request too late or not. If you risk
getting there too late you better rewrite your code)
2. Easier to implement a promises-style API on top of indexedDB.
3. More similar to for example XMLHttpRequest
The downside is:
1. Have to use a bigger syntax to get to the result. "event.result"
vs. "event.target.result".
/ Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
What's the current thinking in terms of events that we're firing? I remember we talked about this a bit, but I don't remember the conclusion and I can't find it captured anywhere. Here's a brain dump of the requirements as I remember them: * Everything should have a source attribute. * Everything done in the context of a transaction should have a transaction attribute. (Probably even errors, which I believe is not the current case.) * Only success events should have a result. * Only error events should have a code and a messageor should they just have an error attribute which holds an IDBDatabaseError object? (If it's the former, then do we even need an interface for IDBDatabaseError to be defined?) * IIRC, Jonas suggested at some point that maybe there should be additional attributes beyond just the source and/or objects should link to their parents. (The latter probably makes the most sense, right? If so, I'll bug it.) Is there anything I'm missing? As far as I can tell, this means we need 5 events: an IDBEvent (with source) and then error with transaction, error without, success with, and success without. That seems kind of ugly though. Another possibility is that we could put a transaction attribute on IDBEvent that's null when there's no transaction. And then error and success would have their own subclasses. To me, this sounds best. Thoughts? J On Fri, Nov 19, 2010 at 3:44 AM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348 > > Summary: [IndexedDB] Overhaul of the event model > Product: WebAppsWG > Version: unspecified > Platform: PC >OS/Version: All >Status: NEW > Severity: normal > Priority: P2 > Component: Indexed Database API >AssignedTo: dave.n...@w3.org >ReportedBy: jor...@chromium.org > QAContact: member-webapi-...@w3.org >CC: m...@w3.org, public-webapps@w3.org > > > We talked about this for a while at TPAC. Here's what I think we agreed > upon > at the time: > > * All events should propagate from the IDBRequest to the IDBTransaction to > the > IDBDatabase. > > * For error events, preventDefault must be called in order to avoid a > transaction aborting. (When you use onerror, you'd of course use false to > do > so.) > > * If you throw within an event handler, the transaction will abort. (Catch > errors that you don't want to implicitly abort the transaction.) > > * The success event will be non-bubbling (because having onsuccess on > IDBTransaction and IDBDatabase would be confusing). > > * The error event should be added to IDBTransaction and IDBDatabase and > should > bubble. > > * createObjectStore should remain sync and simply abort the transaction on > errors (which are pretty much constrained to quota and internal errors). > > * createIndex is the same, except that indexes with a uniqueness constraint > and > existing data that doesn't satisfy it will present another (and more > common) > case that'll cause the transaction to abort. The spec should have a red > note > that reminds people of this. > > -- > Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. > >
