Bug 100292

Summary: IndexedDB: Remove IDBAny from WebKitIDL
Product: WebKit Reporter: Joshua Bell <jsbell>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: alecflett, dgrogan, haraken
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 97375, 111002    
Bug Blocks:    

Joshua Bell
Reported 2012-10-24 14:52:46 PDT
Similar to https://bugs.webkit.org/show_bug.cgi?id=97375 IDBAny is used for attributes of type "any", and these should be replaceable with ScriptValue: IDBCursor.idl: readonly attribute IDBAny source; IDBRequest.idl: readonly attribute IDBAny source; ^^^ Another IDB type (IDBObjectStore, IDBIndex, etc) - would just need a neutral way to call ScriptValue(to[V8|JS](object)) IDBDatabase.idl: readonly attribute IDBAny version; ^^^ Number or String - would need a way to initialize ScriptValue from a number/string IDBIndex.idl: readonly attribute IDBAny keyPath; IDBObjectStore.idl: readonly attribute IDBAny keyPath; ^^^ Null, String or DOMStringList IDBRequest.idl: readonly attribute IDBAny result ^^^ All of the above, or arbitrary script value.
Attachments
Joshua Bell
Comment 1 2013-03-07 13:38:53 PST
IDBVersionChangeEvent.idl: readonly attribute IDBAny oldVersion; IDBVersionChangeEvent.idl: readonly attribute IDBAny newVersion; ^^^ Number or String ... I've been thinking about doing this in three parts: (1) Remove IntegerType/StringType/NullType/KeyPathType in favor of just ScriptValueType + the various IDB*Types (2) Reduce the IDBAny type set down to ScriptValue, and have a binding helper that does (RefPtr<T>) -> ScriptValue via toV8/toJS(). (3) Eliminate IDBAny itself IMHO #1 is valuable on its own as it removes the need to create scratch SerializedScriptValues which then are deserialized into ScriptValues. I've started #1 then abandoned this change about 5 times so far. The crux of it is that we need a ScriptExecutionContext at the point where the ScriptValue is created to get an isolate. Right now this easily done in IDBRequest but requires "dirtying" some of the other call sites - adding [CallWith=ScriptExecutionContext] IDL annotations here and there. I've toyed with several API variations, e.g.: * Require a ScriptExecutionContext to be passed to IDBAny constructors - callers need to are otherwise unchanged. * Add IDBBindingUtilities functions for stringToScriptValue(isolate, str), numberToStringValue(isolate, double), etc; IDBAny creators pass in the ScriptValue * Add constructors to ScriptValue: ScriptValue(isolate, double), ScriptValue(isolate, string), ScriptValue::null(isolate), Opinions?
Alec Flett
Comment 2 2013-03-07 14:06:03 PST
I vote for constructors on ScriptValue, the same way SerializedScriptValue already has intValue() and such.
Kentaro Hara
Comment 3 2013-03-07 16:32:51 PST
(In reply to comment #2) > I vote for constructors on ScriptValue, the same way SerializedScriptValue already has intValue() and such. Agreed.
Note You need to log in before you can comment on or make changes to this bug.