[indexeddb] Issues stated on the current spec

Eliot and I went through the spec and identified the various issues stated in it.  Below is our opinion on each of the open issues based on our understanding of the text.  Based on this, there doesn't seem to be anything major that is blocking our ability to successfully move this spec to Last Call beyond the updating of the spec to reflect the new open/setVersion API.  Let us know if you have a different point of view on how to resolve these issues.

Israel

Issues List:

1. Sections: 3.1.2 Object Store 
Issue Text: specify that generators are not shared between stores.
Feedback: We prefer this approach.  We should state this in the spec and remove the issue.
 
2. Section: 3.1.11 The IDBDatabaseException Interface
Issue Text: These codes are in flux and may change entirely as exception/error handling may be changing in the WebIDL spec.
Feedback: It seems we can remove this comment and still go to last call.  We can always change these codes later.

3. Section: 3.2.3 Opening a database [IDBFactory.cmp()]
Issue Text: This should probably take a collation parameter as well. In fact, it might make sense for this to be on the IDBDatabase, IDBObjectStore, and IDBIndex as well and do the comparison with their default collation.
Feedback: Since we're not introducing collations in our APIs for v1, I believe we can remove this comment.

4. Section: 3.2.7 Cursor [IDBCursor.delete()]
Issue Text: This method used to set this cursor's value to null. Do we want to keep that?
Feedback: We believe that for the asynchronous APIs, the cursor is a cached value and therefore it can still be accessed after we call delete.  The reason is that delete is an asynchronous operation that should only affect the server value of the current record.  The impact should only be felt the next time you try to access this record from the server in any operation. We should be able to specify this on the spec and remove the issue.

5. Section: 3.3.3 Object Store [In example]
Issue Text: The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well).
Feedback: I believe this will be simplified with the new version of open which includes the db version.  At that point, I expect this issue to go away.

6. Section: 3.3.4 Index [in example]
Issue Text: The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well).
Feedback: I believe this will be simplified with the new version of open which includes the db version.  At that point, I expect this issue to go away.

7. Section: 3.3.5 Cursor [in IDBCursorSync.delete()]
Issue Text: This method used to set this cursor's value to null. Do we want to keep that?
Feedback: We believe that for synchronous APIs we need to ensure that the client state reflects the server state.  Since this call is synchronous, the value associated with the cursor should be set to null after the delete API is called. We should be able to specify this in the spec and remove the issue.

8. Section: 4.2 Transaction Creation steps
Issue Text: This should be specified more precisely. Maybe with some sort of global variable locked
Feedback: Is this not addressed in the current spec?

9. Section: 4.8 VERSION_CHANGE transaction steps
Issue Text: If .close() is called immediately but a transaction associated with the connection keeps running for a "long time", should we also fire a blocked event?
Feedback: This seems like an optimization that individual User Agents can choose to make without affecting compatibility.  Because of the asynchronous nature of the APIs, this behavior seems to be unavoidable.

10. Section: 4.10 Database deletion steps
Issue Text: Should we allow blocked to be fired here too, if waiting takes "too long"?
Feedback: We don't see the value of calling onblock twice because we don't provide a mechanism to cancel the db deletion transaction.  All the onblock provides web developers is a mechanism for them to notify their users that the db is pending deletion.  This doesn't seem to require more than one onblock.

11. Section: 4.12 Fire an error event
Issue Text: TODO: need to define more error handling here.
Feedback: Not sure what else we need.

12. Section: 5.7 Cursor Iteration Operation
Issue Text: This should only be done right before firing the success event. Not asynchronously before. Not sure how/where to express that.
Feedback: This seems more like a note rather than an issue.  I believe we can just capture what you stated and that should be enough.

Received on Friday, 26 August 2011 23:23:04 UTC