Re: [IndexedDB] Explaining Asynchronous event-style interface

On Sat, Mar 13, 2010 at 9:43 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:

> (starting a new thread to focus discussion on identifying shortcomings of
> currently specced API)
>
> As specced, it is possible to have multiple concurrent requests at various
> API entry points, except for the IndexedDatabaseRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-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.
>
> Once you have an IDBDatabaseRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBDatabaseRequest>object, it is possible to make one request at a time to open a cursor or
> create a transaction. It is possible to do this concurrently with opening
> another database. If multiple concurrent requests are to be made to create
> and/or open object stores or indexes, different connections in the form of
> IDBDatabaseRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBDatabaseRequest>objects will be needed. Again, this appears largely an initial set up kind
> of thing. Besides, given that it is possible to check whether a request is
> in progress, developers can avoid getting into trouble.
>
> One can create as many IDBIndexRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBIndexRequest>
>  and IDBObjectStoreRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBObjectStoreRequest>
>  object as required. Once these objects are created multiple operations
> can be performed in parallel.
>
> Same goes for IDBCursorRequest<http://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBCursorRequest>
>  objects and performing operations on several different such objects.
>
> I am trying to explain this to those who haven't had a chance to review the
> spec but might be able to weigh in on our discussion
>

This is a very good summary.  Thanks Nikunj.

It'd be great if others (especially the proponents of the event based model)
could weigh in on whether they like this and/or what changes they might
make.


>From an implementors perspective: this is actually easier to implement
what's currently specced rather than a callback based model.

If I was trying to write a library on top of IndexedDB that exposes a
callback and/or promise based API, I would rather a callback based, but I
think I could get my job done with this.  For each request object, I'd
probably just create an array and attach it to the object and use that as a
queue of items to be done.  If I wanted to optimize for multiple operations
in flight at any time, I could even maintain pools of connections, object
stores, indexes, etc that automatically grow when too many items get queued
up at once.  I'm not saying it'd be easy, but it's possible.

If I were trying to write code on the bare API, personally I would prefer a
callback based model, but perhaps I'm just odd.  On the other hand, I think
we've made it pretty clear that ease of use is a much lower priority
compared to making an API with a small surface area that is powerful and is
able to be wrapped by user friendly libraries.


So, in summary, I've actually been arguing against what will make my life
easiest.  But maybe we should just leave the async API as is and move on?

I hope others will chime in on this though.  Especially people who were
originally in favor of an event based model.

J