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

[Drew Wilson]

The other approach we discussed was leaving the postMessage() APIs in
WebCore as they are (taking a DOMString parameter) and doing the
serialization/de-serialization in the JS bindings instead.
My one concern about building the serialization into the WebCore postMessage
impls is I didn't quite understand how that would map to ObjC (although for
ObjC we could just continue exposing only postMessage(DOMString) and have
the ObjC bindings wrap the string in an attributeIterator).

My main concern with any approach is that we find a way to share
serialization code between V8 and JSC.

-atw

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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090910/86a38e7f/attachment.html>