Re: [IndexedDB] A "versionchangeblocked" event

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 Thursday, 23 September 2010 21:04:52 UTC