W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

[Bug 9975] New: Mozilla async API proposal

From: <bugzilla@jessica.w3.org>
Date: Mon, 21 Jun 2010 18:44:06 +0000
To: public-webapps@w3.org
Message-ID: <bug-9975-2927@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9975

           Summary: Mozilla async API proposal
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: nikunj.mehta@oracle.com
        ReportedBy: jonas@sicking.cc
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, andreip@google.com, public-webapps@w3.org


A few people from mozilla recently made a proposal for improvements to the
Indexed DB asynchronous interface. The proposal in its entirety is here:

http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0717.html
http://docs.google.com/View?id=dfs2skx2_4g3s5f857

The main changes are:

1. Once a database has been opened (a database connection has been
established) read access to meta-data, such as objectStore and index
names, is synchronous. Changes to such meta data, such as creating
objectStores and indexes, is still asynchronous.
2. You can only add "requests" to read and write data to a transaction
during a transaction callback. There is one exception to this rule
(more below).
3. Transactions are automatically committed. Once a request in a
transaction finishes and there are no more requests queued against the
transaction, the transaction is committed.
4. Cursors do not fire error events if a request to open a cursor
yields zero results or when iterating using a cursor reaches the end
of the found results. Instead, a success event is fired which
indicates that no more results are available.
5. All reads and writes are done through transactions. However in some
places the transaction is implicit (but defined).
6. Access to index objects are done through API on objectStore objects.
7. Separate functions for add/add-or-modify.
8. Calling abort() on read request always cancels the request, even if
the implementation has already read the data and is ready to fire a
success event. The error event is always fired if abort() is called,
and the success event is suppressed.
9. You are allowed to have multiple transactions per database
connection. However if they use overlapping tables, only the first one
will receive events until it is finished (with the usual exceptions of
allowing multiple readers of the same table).


There was one thing in our initial proposal which have met resistance and so
have been dropped:

We're not suggesting any changes to factory functions for KeyRanges at this
point. KeyRange construction changes might not be needed and in any case is
orthogonal to the rest of the proposal so lets not discuss it now.


Additionally, some people were concerned about the getAll/getObjectAll
functions. Though toward the end of that discussion it seemed like people were
less concerned so we might want to include it after all. In any case mozilla is
planning on putting it in our preliminary implementation.

/ Jonas

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Monday, 21 June 2010 18:44:07 GMT

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