This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the IDL is: IDBTransaction transaction (any storeNames, optional DOMString mode); There was discussion on the list about removing "any" and using overloads to define the binding behavior here, e.g.: IDBTransaction transaction (DOMString storeName, optional DOMString mode); IDBTransaction transaction (sequence<DOMString> storeNames, optional DOMString mode); IDBTransaction transaction (DOMStringList storeNames, optional DOMString mode); Not sure if we want sequence<DOMString> or DOMString[] (I think the former is the new hotness); also, not sure if DOMStringList can be defined to "coerce" to sequence<DOMString> to reduce the use of that type.
I don't think we can do this until ReSpec is changed to support it. Please let me know if I'm wrong though. I *think* the proper WebIDL syntax would be enum transactionMode { "readonly, "readwrite" }; IDBTransaction transaction ((DOMString or sequence<DOMString>) storeName, optional transactionMode mode);
More broadly, methods that are currently spec'd to take "any" arguments that could be distinguished by WebIDL overloads should be, as this eliminates the need for this spec to deal with conversions (e.g. is passing a JS number to a function that takes a DOMString allowed or a TypeError?) This does NOT apply to arguments which are keys (which is covered clearly in the spec) or values (ditto, via HTML5 structured clone algorithm) That leaves: IDBDatabase.transaction(any storeNames, ...) IDBObjectStore.createIndex(..., any keyPath, ...) (plus IDB*Sync variants) As an example where spec ambiguity could exist, the behavior of JS and undefined and null values for is well covered by the WebIDL spec in the case of db.createObjectStore(name, {keyPath: VALUE_IN_QUESTION}) but not in the case of store.createIndex(name, VALUE_IN_QUESTION). Ensuring that the interpretation the keyPath value in both methods is dictated by WebIDL seems highly desirable.
Robin, any plans to get ReSpec fixed to support these types of things?
This should be resolved in: https://dvcs.w3.org/hg/IndexedDB/rev/b6d2f7b5a5a0 Since I filed this, I'd appreciate it if someone else could verify that the changes make sense.
For what it's worth, the changes make sense to me as a binding implementor. I can't speak for whether they make sense for indexeddb per se...