This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
---------- Forwarded message ---------- From: Dominique Hazael-Massieux <dom@w3.org> Date: Fri, May 21, 2010 at 9:57 AM Subject: IndexedDB WebIDL bugs To: public-webapps <public-webapps@w3.org> Hi, Glancing quickly at the editors draft of http://dev.w3.org/2006/webapi/WebSimpleDB/ and with help from the WebIDL checker, I've found the following problems: * none of the interfaces/exceptions are marked with the extended attribute [NoInterfaceObject] I doubt they are all meant to be visible in the global namespace * The IDBDatabaseException Interface uses the "attribute" keyword for "code" and "message" - exceptions don't have attributes, the keyword should be removed * IDBDatabaseSync.createObjectStore uses an extended attribute "[Null=Null]" on its second parameter - I suspect it was meant to be "[TreatUndefinedAs=Null]", and if so, the type of the parameter should be "DOMString?" rather than DOMString Based on the discussions on the list, and as the beginning of 3.3 seems to allude to, synchronous operations are only going to be used in Workers; I suggest to state that clearly, and also to start the first example of the spec with the async example if that's the one that is most likely to be used. Dom
> * none of the interfaces/exceptions are marked with the extended > attribute [NoInterfaceObject] I doubt they are all meant to be visible > in the global namespace These interfaces are marked with [NoInterfaceObject]: IDBEnvironment IDBEnvironmentSync IDBTransactionCallback > * The IDBDatabaseException Interface uses the "attribute" keyword for > "code" and "message" - exceptions don't have attributes, the keyword > should be removed "attribute" keyword removed from both. > * IDBDatabaseSync.createObjectStore uses an extended attribute > "[Null=Null]" on its second parameter - I suspect it was meant to be > "[TreatUndefinedAs=Null]", and if so, the type of the parameter should > be "DOMString?" rather than DOMString Cannot repro. I believe this was removed previously. > Based on the discussions on the list, and as the beginning of 3.3 seems > to allude to, synchronous operations are only going to be used in > Workers; I suggest to state that clearly, and also to start the first > example of the spec with the async example if that's the one that is > most likely to be used. Section 3.3 begins: The synchronous database API methods provide a blocking access pattern to IndexedDB databases. Since they block the calling thread they are only available from workers. The first sample is asynchronous. I believe that this covers all of the requests in this bug. I am going to go ahead and resolve it. Let me know if there's anything else needed for this one. Thanks, Eliot