Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Sat, Feb 19, 2011 at 8:46 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org 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 Tue, Feb 22, 2011 at 2:48 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Feb 19, 2011 at 8:46 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org 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 Fri, Feb 18, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org 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 dgro...@chromium.org wrote:
On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org
wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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 jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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 11:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org
wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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, 07 Feb 2011 18:15:04 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters sim...@opera.com wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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: link style script img object video source track input ApplicationCache Worker SharedWorker EventSource WebSocket frame Should any of those also fire an event to window.onerror as their error event's default action? All of them? What I'm trying to do is to get some consistency so the Web platform doesn't appear so designed by committee where half the errors are reported to window.onerror and the other half not. It makes stuff harder to learn. 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. OK. Opera follows the spec, FWIW. -- 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 sim...@opera.com wrote: On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters sim...@opera.com wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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: link style script img object video source track input ApplicationCache Worker SharedWorker EventSource WebSocket frame Should any of those also fire an event to window.onerror as their error event's default action? All of them? What I'm trying to do is to get some consistency so the Web platform doesn't appear so designed by committee where half the errors are reported to window.onerror and the other half not. It makes stuff harder to learn. 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. 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. That said, maybe we should fire window.onerror for many of the things that you list above. 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? / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking jo...@sicking.cc 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:41 PM, Simon Pieters sim...@opera.com wrote: On Mon, 14 Feb 2011 19:59:37 +0100, Jonas Sicking jo...@sicking.cc 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, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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 7:53 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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 Thu, Feb 10, 2011 at 7:06 PM, ben turner bent.mozi...@gmail.com 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
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:30 AM, ben turner bent.mozi...@gmail.com 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
On Fri, Feb 11, 2011 at 11:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 11, 2011 at 11:30 AM, ben turner bent.mozi...@gmail.com 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 Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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 Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
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
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 Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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 Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters sim...@opera.com wrote: On Wed, 02 Feb 2011 23:28:56 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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
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, bugzi...@jessica.w3.org 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
On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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
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 jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow jor...@chromium.org 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 3:19 PM, Jeremy Orlow jor...@chromium.org 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
On Wed, Feb 2, 2011 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 2, 2011 at 3:19 PM, Jeremy Orlow jor...@chromium.org 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
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
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
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
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
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 Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org 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
On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer a...@rauschma.de 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
On Thu, Jan 27, 2011 at 5:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer a...@rauschma.de 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 7:16 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 27, 2011 at 5:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer a...@rauschma.de 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
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
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
On Thu, Jan 27, 2011 at 8:20 PM, ben turner b...@mozilla.com 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
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, bugzi...@jessica.w3.org 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.
