Re: [IndexedDB] Explaining Asynchronous event-style interface

On Tue, Mar 30, 2010 at 9:37 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

> 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.
>

The implementation I'm working on in WebKit is callback(s passed into each
method call) based.  I guess this will make it easier to compare and
contrast the approaches.

J