Re: [IndexedDB] A "versionchangeblocked" event

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 Thursday, 23 September 2010 17:14:46 UTC