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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
