17649 2012-06-29 13:27:33 +0000 Address WebIDL comments from Kyle Huey and Ms2ger 2013-03-01 22:27:11 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified PC All RESOLVED FIXED P2 normal --- 1 jonas jsbell eliotgra jsbell mike mounir Ms2ger public-webapps robin public-webapps-bugzilla oldest_to_newest 69534 0 jonas 2012-06-29 13:27:33 +0000 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1152.html I'm not sure that we can address all of them, such as the enum ones, due to limitations in ReSpec 71337 1 eliotgra 2012-07-23 23:45:00 +0000 Jonas, I'm assigning this to you. I've taken care of some of Kyle's feedback, but I'll defer to you on things like the default values for the enums. I've FIXED the following: 3.1.9 The return type of the static functions on IDBKeyRange is not 'static IDBKeyRange', it is just 'IDBKeyRange'. 3.2.1 The correct type name is "object", not "Object" (note the capitalization). IDBRequest.readyState should be an enum type, not a DOMString. 3.2.2 IDBVersionChangeEvent should probably reference whatever spec defines how constructors work for DOM events. 3.2.7 "Object" should be "object". 3.2.8 IDBTransaction's mode attribute should be an enum type. I DID NOT FIX the following items in the mail: 3.2.4 IDBDatabase.transaction's mode argument should be an enum type, with a default value specified in IDL instead of in prose. 3.2.5 Is it intentional that IDBObjectStore.indexNames does not return the same DOMStringList every time, unlike IDBDatabase.objectStoreNames (yes, I realize that the circumstances under which the former can change are much broader). IDBObjectStore.openCursor's direction argument should be an enum type, with a default value specified in IDL (right now it is unspecified). 3.2.6 IDBIndex.openCursor and IDBIndex.openKeyCursor's direction argument should be an enum type, with a default value specified in IDL. Also, it would be nice if we could tighten up keys from 'any' to a union. 79852 2 jsbell 2012-12-10 18:50:22 +0000 One more I didn't see in Kyle's list: 3.1.12 Options Object - IDBObjectStoreParameters is defined as: dictionary IDBObjectStoreParameters { DOMString? keyPath = null; boolean autoIncrement = false; }; But the prose says: "If the optionalParameters argument is specified and has a keyPath property which is not undefined or null, then set keyPath to the value of this property. If keyPath is an Array, then each item in the array is converted to a string. If keyPath is not an Array, it is converted to a string." The IDL should either be: DOMString? keyPath = null; or: (sequence<DOMString> or DOMString)? keyPath = null; 81943 3 jsbell 2013-01-22 17:07:28 +0000 Adding more IDL nits from Ms2ger - some overlap with items in this issue already, which is why I'm not filing a separate bug. Original messages dated January 21, 2013: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/ (1) IDBKeyRange should have static functions From the examples in the IDB specification (in [1], for example) and from existing implementations, it appears that the functions on the IDBKeyRange interface (only, lowerBound, upperBound and bound) should be static. However, there is no actual normative requirement to that effect; instead, the IDL snippet requires those functions to only be callable on IDBKeyRange instances. [2] [1] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#key-generator-concept [2] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#idl-def-IDBKeyRange (2) Event handlers The IDB specification still uses IDL like [TreatNonCallableAsNull] attribute Function? onsuccess; for its event handlers. Current practice is to use attribute EventHandler onsuccess; (3) Type of IDBRequest.source IDBRequest.source has type "object" in the IDL snippet, but the definition claims the attribute can return null. If this is the case, the type should be "object?", as for all nullable types. (4) Type of IDBRequest.readyState interface IDBRequest : EventTarget { // … readonly attribute enum readyState; // … }; However, "enum" is not a type. The correct syntax would be something like enum IDBReadyState { "pending", "done" }; interface IDBRequest : EventTarget { // … readonly attribute IDBReadyState readyState; // … }; (5) Type of IDBCursor.source IDBCursor.source is described as returning "object". It would be better to return the union (IDBObjectStore or IDBIndex), to make it clear that that is what's intended. 81948 4 jsbell 2013-01-22 17:12:57 +0000 (In reply to comment #2) > The IDL should either be: > > DOMString? keyPath = null; I believe I meant: any? keyPath = null; But the union is preferable. 83850 5 jsbell 2013-02-28 23:40:30 +0000 From Ms2ger's list: (1) IDBKeyRange should have static functions - Resolved as https://dvcs.w3.org/hg/IndexedDB/rev/bf71413d740c (2) Event handlers - Resolved as https://dvcs.w3.org/hg/IndexedDB/rev/09a89b16b4b2 (3) Type of IDBRequest.source - Resolved as https://dvcs.w3.org/hg/IndexedDB/rev/0f8193ddb6af (4) Type of IDBRequest.readyState - Resolved as https://dvcs.w3.org/hg/IndexedDB/rev/18b6e04cc02c #5 is not yet fixed, and #3 could be improved to be: readonly attribute (IDBObjectStore or IDBIndex or IDBCursor)? source; ... but I'm hitting a ReSpec.js bug (?) with unions 83851 6 jsbell 2013-03-01 00:10:19 +0000 (In reply to comment #1) > 3.2.6 > > IDBIndex.openCursor and IDBIndex.openKeyCursor's direction argument should > be an enum type, with a default value specified in IDL. Resolved in: https://dvcs.w3.org/hg/IndexedDB/rev/47815a2eaed6 83852 7 jsbell 2013-03-01 00:11:41 +0000 (In reply to comment #6) > (In reply to comment #1) > > 3.2.6 > > > > IDBIndex.openCursor and IDBIndex.openKeyCursor's direction argument should > > be an enum type, with a default value specified in IDL. > > Resolved in: https://dvcs.w3.org/hg/IndexedDB/rev/47815a2eaed6 Whoops, that covers this as well: > IDBObjectStore.openCursor's direction argument should be an enum type, with > a default value specified in IDL (right now it is unspecified). 83854 8 jsbell 2013-03-01 00:28:19 +0000 (In reply to comment #1) > 3.2.4 > > IDBDatabase.transaction's mode argument should be an enum type, with a > default value specified in IDL instead of in prose. Resolved in https://dvcs.w3.org/hg/IndexedDB/rev/8e121d53f2f6 (although I left the prose in there as well). 83855 9 jsbell 2013-03-01 00:47:52 +0000 > Also, it would be nice if we could tighten up keys from 'any' to a union. This is tracked w/ suggested fix as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20582 ... Here's what remains: > 3.2.5 > > Is it intentional that IDBObjectStore.indexNames does not return the same > DOMStringList every time, unlike IDBDatabase.objectStoreNames (yes, I > realize that the circumstances under which the former can change are much > broader). That requires thinking. "Next!" The rest are all union types, blocked on a ReSpec bug (?) to get the IDL perfect: > dictionary IDBObjectStoreParameters { > DOMString? keyPath = null; > boolean autoIncrement = false; > }; Should be: (sequence<DOMString> or DOMString)? keyPath = null; Or as a fallback: any? keyPath = null; > Type of IDBRequest.source Should be: (IDBObjectStore or IDBIndex or IDBCursor)? > Type of IDBCursor.source Should be: (IDBObjectStore or IDBIndex) 83864 10 Ms2ger 2013-03-01 10:09:58 +0000 Robin? 83865 11 robin 2013-03-01 11:55:01 +0000 (In reply to comment #10) > Robin? This should all be fixed in 3.1.46 that just shipped. 83871 12 jsbell 2013-03-01 17:50:51 +0000 > > Type of IDBRequest.source > > Should be: (IDBObjectStore or IDBIndex or IDBCursor)? Fixed! https://dvcs.w3.org/hg/IndexedDB/rev/8a1cffca7f26 > > Type of IDBCursor.source > > Should be: (IDBObjectStore or IDBIndex) Fixed! https://dvcs.w3.org/hg/IndexedDB/rev/8a1cffca7f26 (In reply to comment #9) > > > dictionary IDBObjectStoreParameters { > > DOMString? keyPath = null; > > boolean autoIncrement = false; > > }; > > Should be: (sequence<DOMString> or DOMString)? keyPath = null; ReSpec.js is truncating "sequence<DOMString>" into "sequence". Mail to Robin written but not yet sent. :) 83872 13 jsbell 2013-03-01 18:00:34 +0000 (In reply to comment #12) > > ReSpec.js is truncating "sequence<DOMString>" into "sequence". Mail to Robin > written but not yet sent. :) My bad, I wasn't escaping in the HTML. Derp. 83873 14 jsbell 2013-03-01 18:08:08 +0000 > > dictionary IDBObjectStoreParameters { > > DOMString? keyPath = null; > > boolean autoIncrement = false; > > }; > > Should be: (sequence<DOMString> or DOMString)? keyPath = null; Fixed! https://dvcs.w3.org/hg/IndexedDB/rev/dffdbbe300ab This leaves the DOMStringList question re: 3.2.5 83890 15 jsbell 2013-03-01 22:26:20 +0000 (In reply to comment #1) > 3.2.5 > > Is it intentional that IDBObjectStore.indexNames does not return the same > DOMStringList every time, unlike IDBDatabase.objectStoreNames (yes, I > realize that the circumstances under which the former can change are much > broader). Is this question about the identity of the DOMStringList object returned by the property accesses, or about the values contained in the lists? I'm choosing to focus on the inconsistencies between the property definitions. I've added the same text about snapshotting to indexNames as is present on objectStoreNames. If that's not the intent of the question, can we file a new bug? Resolved in https://dvcs.w3.org/hg/IndexedDB/rev/49660ca248b0 83891 16 jsbell 2013-03-01 22:27:11 +0000 I believe all issues mentioned in this bug have now been addressed. If not, we should probably file a new, much shorter bug. :)