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 matching the object clone semantic. JSON was never
sufficient for the purpose of postMessage, and is also relatively
trivially breakable.
--Oliver
On Sep 10, 2009, at 5:29 PM, Drew Wilson wrote:
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 having a common serialization format would be
useful, but I agree - it probably is better to just send opaque
objects around, which might enable WebKit to send actual cloned
object instances without requiring any serialization, while chromium
can do the serialization itself when sending the data cross-process.
-atw
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
