[webkit-dev] Passing data structures through postMessage()

[Chris Campbell]

Hi All,

I had it in mind to implement support for passing data structures
through postMessage() using the "structured clone" algorithm laid out
in the HTML5 spec:

http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data

I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.

Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.

The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type.  AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it.  I'm thinking
it would look something like this:

interface AttributeIterator {
    bool isUndefined();
    bool isNull();
    bool isFalse();
    bool isTrue();
    bool isNumber();
    String getNumber();
    bool isString();

    // ... cover the other types including Date, RegExp, ImageData,
    // File, FileData, and FileList ...

    // Retrieve the key for the next property (for Objects and Arrays)
    String nextEnumerableProperty();

    AttributeIterator getPropertyValue(key);
}


I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handle<v8::Value> or JSC::JSvalue value.

Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string.  Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.


Open questions:

(1) Is passing an AttributeIterator type into postMessage() really the
best way to go?  Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...

(2) Where should AttributeIterator live in the source tree?

(3) Where should the serialization and deserialization routines live
in the source tree?

(3) I haven't addressed the specifics of the serialized string format.
 Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc..  However, I'm not too worried
about coming up with a suitable format for this.


Comments, advice, admonitions welcome!  :)

Regards,
--Chris