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

[Sam Weinig]

On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell <campbell at flock.com> wrote:

> 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
>

It should not be necessary to serialize to a string just to pass the
structured clones across thread boundaries.  This would be an especially bad
idea for things like CanvasPixelArray.  I am also not sure I understand the
name AttributeIterator.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090910/7fdac0d1/attachment.html>