On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 3:12 PM, Chris Campbell 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:
Note that ImageData is cloned/copied when sent via postMessage(). So you end
up with a copy of the ImageData, obviating the need for locks.
I think (per my private mail to Darin which I'm restating here) that the use
case is doing some kind of raytracing or something in a Worker, posting the
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
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
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:
On Thu, Sep 10, 2009 at 3:55 PM, Drew Wilson atwil...@google.com wrote:
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
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt oli...@apple.com wrote:
This is incorrect, from the bindings point of view the type here should be
any, which in the JS bindings means ScriptValue. The actual serialisation
is by definition bindings dependent, be that JSC or ObjC.
Certainly,
No, it is more restrictive now than it was 6 months ago -- I was
attempting to implement this back then and the ambiguity in handling
the more excitingly complex objects (now simply return null) made it
substantially more complex, that is the only reason the implementation
is not currently
I'm not sure that it is actually more restrictive now than it was 6 months
ago. I assume you're looking at this:
http://www.w3.org/TR/2009/WD-html5-20090212/infrastructure.html#safe-passing-of-structured-data
where it seems to say that all host objects (DOM objects, etc) are cloned as
null.
Given shared workers (and indeed Chromium's out-of-process dedicated
workers), it seems like we also have cross process boundaries to consider.
-Darin
On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 3:12 PM, Chris Campbell wrote:
Hi All,
I had
10 matches
Mail list logo
