<br><br><div class="gmail_quote">On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell <span dir="ltr">&lt;<a href="mailto:campbell@flock.com">campbell@flock.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi All,<br>
<br>
I had it in mind to implement support for passing data structures<br>
through postMessage() using the &quot;structured clone&quot; algorithm laid out<br>
in the HTML5 spec:<br>
<br>
<a href="http://dev.w3.org/html5/spec/Overview.html#posting-messages" target="_blank">http://dev.w3.org/html5/spec/Overview.html#posting-messages</a><br>
<a href="http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data" target="_blank">http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data</a><br>
<br>
I&#39;ve had some brief discussion with Dave Levin and Drew Wilson on<br>
#chromium IRC about this, and have an approach in mind that follows<br>
and elaborates on their suggestions, but there are still some holes in<br>
it and I&#39;d very much like input from people familiar with this area.<br>
<br>
Currently, there are several postMessage() handlers (in<br>
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and<br>
Worker.idl), and they all take a DOMString for the message parameter.<br>
<br>
The general idea is to change that message parameter from a DOMString<br>
to a new AttributeIterator type that allows walking of any sort of JS<br>
structure/type.  AttributeIterator would essentially be an adapter to<br>
translate native V8 or JSC JavaScript objects to an agnostic interface<br>
suitable for walking the structure and serializing it.  I&#39;m thinking<br>
it would look something like this:<br>
<br>
interface AttributeIterator {<br>
    bool isUndefined();<br>
    bool isNull();<br>
    bool isFalse();<br>
    bool isTrue();<br>
    bool isNumber();<br>
    String getNumber();<br>
    bool isString();<br>
<br>
    // ... cover the other types including Date, RegExp, ImageData,<br>
    // File, FileData, and FileList ...<br>
<br>
    // Retrieve the key for the next property (for Objects and Arrays)<br>
    String nextEnumerableProperty();<br>
<br>
    AttributeIterator getPropertyValue(key);<br>
}<br>
<br>
<br>
I&#39;m also thinking that depending on compile-time flags, the<br>
contstructor for AttributeIterator would either take a<br>
v8::Handle&lt;v8::Value&gt; or JSC::JSvalue value.<br>
<br>
Then in each implementation of postMessage() the AttributeIterator<br>
instance could be passed to the structured clone serializer, which<br>
would return a string.  Thereafter, no changes would be required to<br>
WebCore internals since they already pass strings around... until on<br>
the receiving end we get to MessageEvent.data where we would do the<br>
deserialization in a custom getter.<br>
<br>
<br>
Open questions:<br>
<br>
(1) Is passing an AttributeIterator type into postMessage() really the<br>
best way to go?  Drew mentioned that this might incur a bunch of ObjC<br>
binding work on the JSC side...<br>
<br>
(2) Where should AttributeIterator live in the source tree?<br>
<br>
(3) Where should the serialization and deserialization routines live<br>
in the source tree?<br>
<br>
(3) I haven&#39;t addressed the specifics of the serialized string format.<br>
 Plain JSON is not quite sufficient since it doesn&#39;t retain type<br>
information for Date, RegExp, etc..  However, I&#39;m not too worried<br>
about coming up with a suitable format for this.<br>
<br>
<br>
Comments, advice, admonitions welcome!  :)<br>
<br>
Regards,<br>
--Chris<br>
</blockquote><div><br></div><div>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.  </div>
<div><br></div><div>-Sam</div><div><br></div></div>