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
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
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
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 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
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 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
>
> 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 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
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 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 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
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
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 also have a patch (https://bugs.webkit.org/show_bug.cgi?id=28930) that's
awaiting a resolution of this for desktop notifications. Does anyone object
to putting "experimental" in the name of the setting as a good solution?
-John
On Wed, Sep 9, 2009 at 9:50 AM, Eric Seidel wrote:
> experiment
Don't know how come she came to my kitchen ..its ground floor and window
remains open... It was too young to move around also.. Fed it milk with
hand..slowly she got used to us...
You take care no problem. :) learning the old ones tend to forget :).
Good night ..sweet dreams...
Love
Prema
---
Hello all:
I noticed some missing functionality in WebKit's implementation of
Microsoft Active Accessibility. In particular, the accSelect method
ofthe IAccessible interface is not implemented; I've opened a bug on
this in Bugzilla. So I'm offering to do some work in this area, but I
don't
On Sep 10, 2009, at 9:04 AM, Kent Hansen wrote:
JavaScriptCore uses some compile-time defines to decide which flags
to pass to vm_map() and mmap(), depending on the Mac OS version.
Now, if WebKit is built and run on the same version, that's
obviously fine, but we've found that if we build o
Hi,
JavaScriptCore uses some compile-time defines to decide which flags to
pass to vm_map() and mmap(), depending on the Mac OS version. Now, if
WebKit is built and run on the same version, that's obviously fine, but
we've found that if we build on Tiger but run on Leopard, the vm_map()
call fails.
19 matches
Mail list logo
