W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] A "versionchangeblocked" event

From: ben turner <bent.mozilla@gmail.com>
Date: Fri, 24 Sep 2010 07:50:29 -0700
Message-ID: <AANLkTim1OkAav1GTJ3tt9tAa2HejS+5qDO=WuKMkZe6D@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
The strategy we decided on was to send a 'versionchange' event to
every database that isn't closed first. Then we loop again and if
there are any left that are not closed we fire the blocked event.
Since we expect pages to call close() inside their 'versionchange'
handler we shouldn't be firing the blocked event unless it's really
necessary.

-Ben

On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> Are we really sure this is needed?
> I was just writing up a bug for this and started to wonder if we needed any
> event when there no longer is a block.  I then realized that once you're
> unblocked the onsuccess should fire immediately, so there's no need.  But
> wait...isn't this true of normal blocking as well?  Basically either the
> onsuccess will fire immediately or onblocked will.  So couldn't an app just
> assume it's blocked until it receives a onsuccess message?  The worst case
> is that the web app blinks up some message to the user to close other
> windows, but it seems like that could happen even with an onblocked event
> being added.  Am I missing something here?
> J
> On Thu, Sep 23, 2010 at 9:57 PM, ben turner <bent.mozilla@gmail.com> wrote:
>>
>> I'm voting for 1! I'd hate to give all the other requests a property
>> that only setVersion requests will use.
>>
>> -Ben
>>
>> On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> > On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow <jorlow@chromium.org>
>> > wrote:
>> >> On Wed, Sep 22, 2010 at 9:07 PM, ben turner <bent.mozilla@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> While implementing the latest setVersion changes Jonas and I decided
>> >>> that it would be really useful to be able to signal to the caller that
>> >>> other web pages are open and using the database (thus preventing a
>> >>> setVersion transaction from running).
>> >>>
>> >>> Consider a web page open in two windows, one minimized or otherwise
>> >>> obscured and the other in the foreground. If the background window is
>> >>> running a transaction then the foreground window will not be able to
>> >>> immediately begin a setVersion transaction when it makes that request.
>> >>> The spec currently informs the background page that it should close
>> >>> all its databases, but it would be even more useful to inform the
>> >>> foreground page that it is currently blocked. That way the foreground
>> >>> page could display some kind of notification ("Hey, you! Go close your
>> >>> other tabs if you want us to upgrade the database!") that would aid
>> >>> the process. We are also relying on page authors to correctly call
>> >>> close() on their databases in response to the "versionchanged" event
>> >>> and I don't believe that they will always follow through.
>> >>>
>> >>> Jonas and I thought of three possibilities:
>> >>>
>> >>> 1. Make setVersion return a special kind of request that had an
>> >>> "onblocked" event handler. The caller could then add a handler just as
>> >>> they do for success and error conditions.
>> >>> 2. Make all IDBRequests have an "onblocked" handler, but just never
>> >>> call it in other situations.
>> >>> 3. Fire a "versionchangeblocked" event at the database.
>> >>>
>> >>> What do you guys think? Any preferences? I don't really like 2, and
>> >>> I've preemptively implemented 3, but I'm not in love with 1 or 3
>> >>> either.
>> >>
>> >> This exact thing came up when we originally talked about setVersion.  I
>> >> thought Jonas proposed and we decided on 1 (though I'm not against
>> >> 3)..?
>> >>  Did this just not make it into the spec?
>> >
>> > I think that 1 and 2 are the best solutions and I too thought that
>> > that was what we had decided on. I don't really see the advantage with
>> > 3 since it means that you have to register event handlers on two
>> > separate objects, and potentially worry about colliding with other
>> > pieces of code doing version upgrades (though the latter problem seems
>> > somewhat far fetched).
>> >
>> > IMHO 2 seems simpler but I don't really care between 1 and 2. I'll
>> > note that there is lots of precedence in the HTML5 spec of adding
>> > attribute handlers on objects even though they don't necessarily fire
>> > on the given object. This was done to keep down the number of
>> > interfaces and thus keep things simpler.
>> >
>> > But if people prefer 1 I'm game for that too.
>> >
>> > / Jonas
>> >
>
>
Received on Friday, 24 September 2010 14:51:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT