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 ha
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
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
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, J
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 Sick
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 do
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
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
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 sou
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 err
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
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 win
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 t
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
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 th
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 cod
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 someh
> 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 fro
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 do
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
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. Her
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->transacti
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-bubb
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 stron
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 wr
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
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: uns
>> 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 li
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 sound
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 flexi
> 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 invocati
> 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 A
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
>> 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
> 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
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 outpu
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 in
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, LOADIN
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? I
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 t
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
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
42 matches
Mail list logo
