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,
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
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
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,
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
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
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:
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 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
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
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
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 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
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
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
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
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
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
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
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
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,
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
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
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,
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.
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?
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
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
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
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
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
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
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
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
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
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
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
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
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.
*
39 matches
Mail list logo
