W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [IndexedDB] Explaining Asynchronous event-style interface

From: Shawn Wilsher <sdwilsh@mozilla.com>
Date: Tue, 30 Mar 2010 13:37:27 -0700
Message-ID: <4BB26107.5070306@mozilla.com>
To: Nikunj Mehta <nikunj@o-micron.com>
CC: public-webapps WG <public-webapps@w3.org>
On 3/22/2010 10:49 AM, Shawn Wilsher wrote:
> On 3/13/2010 1:43 AM, Nikunj Mehta wrote:
>> As specced, it is possible to have multiple concurrent requests at
>> various API entry points, except for the IndexedDatabaseRequest
>> interface. In this particular case, you can only have one request to
>> open a database in a Window object. Given that this is setup kind of
>> work, it does not appear that this limitation amounts to much. If
>> multiple connections to a single DB are required, or if different DBs
>> have to be opened, that would have to be done sequentially, i.e., start
>> a new request only after the previous one completed.
> This seems like an artificial constraint to me. Is there any reason why
> we couldn't open up more than one database connection at a time (or at
> least allow the possibility for a UA to do so).
In fact, I realized a use case today that makes this constraint 
difficult to work around.  Say you have two different libraries that use 
indexedDB.  You'll now have to be careful when you initialize each 
library so they don't try to open a database at the same time.  Even 
then, if they open up databases on the fly, you'd have to be very 
careful to make sure they don't stomp on each other.

Having open return an IDBRequest and not having the request property on 
IndexedDatabaseRequest would solve this problem.  I'm going to prototype 
an implementation in Mozilla this way to see if any issues come up, but 
I don't currently foresee any.

Cheers,

Shawn



Received on Tuesday, 30 March 2010 20:36:39 GMT

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