On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell <campb...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev