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 unde
On Thu, 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:
>
> http://dev.w3.org/html5/spec/Overview.html#posting-messages
> htt
On Thu, Sep 10, 2009 at 3:55 PM, Drew Wilson 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 building the serializa
On Thu, Sep 10, 2009 at 4:55 PM, Sam Weinig wrote:
> 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 AttributeIte
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:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/h
>
> Perhaps it's not necessary to serialize to a string. However, there
> is existing code that passes strings through and it would be nice not
> to have to change all that. Binary image data could be text-encoded.
> That said, I'm open to binary serialization if it's not too big a
> change.
>
>
On Sep 10, 2009, at 5:09 PM, Chris Campbell wrote:
On Thu, Sep 10, 2009 at 4:55 PM, Sam Weinig
wrote:
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
Good point - re-reviewing the Structured Clone spec, I see all kinds of
crazy stuff is cloneable now, so string/JSON may not be a particularly good
basis. It seems that we'll need to support File access from Workers, since
you can clone/send those objects over from page context.
I had expected that
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt 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, from a WebID
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 currentl
On Sep 10, 2009, at 5:32 PM, Drew Wilson wrote:
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt 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
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". Sou
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 wrote:
>
> On Sep 10, 2009, at 3:12 PM, Chris Campbell wrote:
>
> Hi All,
>>
>> I had it in
On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak 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
result
I see. Thanks, yeah... I misremembered how ImageData works :-/-Darin
On Fri, Sep 11, 2009 at 11:03 AM, Drew Wilson wrote:
> 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 mai
17 matches
Mail list logo
