Re: [dev-servo] Handling adoptNode

2012-10-24 Thread Robert O'Callahan
On Sun, Oct 21, 2012 at 6:50 PM, Patrick Walton pwal...@mozilla.com wrote: It seems to me that Google Chrome would have the same problems here, since it runs different origins in different processes. AFAIK, in Chrome, if two JS documents can reference each other's heaps, it puts them in the

Re: [dev-servo] Handling adoptNode

2012-10-24 Thread Robert O'Callahan
On Sat, Oct 20, 2012 at 9:55 AM, Boris Zbarsky bzbar...@mit.edu wrote: Do we have a plan for adoptNode? If we're allocating nodes out of the JS heap, presumably we'll need to brain-transplant the JSObject and then copy over the implementation into the new compartment... and make sure we

Re: [dev-servo] Handling adoptNode

2012-10-24 Thread Boris Zbarsky
On 10/24/12 7:04 PM, Robert O'Callahan wrote: Couldn't we replace the original with a proxy that forwards to the new object? For access from JS that's exactly what we'll do. The question is what happens for access from Rust. -Boris ___ dev-servo

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Benjamin Smedberg
On 10/22/2012 7:59 AM, David Bruant wrote: Is adoptNode an important API? It's not a good design in my view, but I'm in a glass house when it comes to criticizing DOM APIs :-P. Perhaps it's ok for performance to be in a penalty box for adoptNode. As a web developer, I've never used adoptNode, I

Re: [dev-servo] Handling adoptNode

2012-10-22 Thread Brendan Eich
Boris Zbarsky wrote: On 10/22/12 6:58 AM, Brendan Eich wrote: Is adoptNode an important API? Define important? Defined in terms of not important == can put in perf penalty box of some non-trivial penalty-size. Still could have too high a penalty, but we can roll the dice with Servo. /be