Bug 100292 - IndexedDB: Remove IDBAny from WebKitIDL
Summary: IndexedDB: Remove IDBAny from WebKitIDL
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 97375 111002
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-24 14:52 PDT by Joshua Bell
Modified: 2013-04-11 09:13 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 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.
Comment 1 Joshua Bell 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?
Comment 2 Alec Flett 2013-03-07 14:06:03 PST
I vote for constructors on ScriptValue, the same way SerializedScriptValue already has intValue() and such.
Comment 3 Kentaro Hara 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.