<br><br><div class="gmail_quote">On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler <span dir="ltr"><<a href="mailto:daniel.gredler@gmail.com">daniel.gredler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><br></blockquote></div><div>I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out there with comments?<br>

</div></div></blockquote><div><br></div><div>I've often had the same thought (that there's no reason we shouldn't handle cycles when implementing structured clones).</div><div><br></div><div>That said, I'm compelled to point out that WebKit browsers only support string messages currently (they don't yet implement the structured clone part of the spec). And none of the currently shipping browsers support MessagePorts or SharedWorkers (although WebKit browsers are getting these soon). So given that there's a workaround for the lack of support for cycles in structured clones (applications can do their own serialization) but there's no app-level workaround for the lack of SharedWorkers, I'd rather see vendors concentrate on implementing the current spec before adding greater support for cloning message parameters.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>I agree that once you've made the decision to not clone functions, cloning the prototype chain becomes (nearly?) useless. However, I'd be interested to know the rationale behind this decision, since Web Workers appear to follow the same-origin policy (e.g. "If the origin of the resulting absolute URL is not the same as the origin of the script that invoked the constructor, then throw a security exception", etc). I assume there's a security concern lurking somewhere?</div>
</div></blockquote><div><br></div><div>It's not clear to me how you'd clone the lexical scope of a function and carry it over to the worker in a way that doesn't cause synchronization issues.</div><div><br></div>
<div>Case in point:</div><div><br></div><div>var obj = {};</div><div>var foo = "abc";</div><div>obj.bar = function() { foo = "def"; }</div><div>sharedWorker.port.postMessage(obj);</div><div><br></div><div>
Now, from shared worker scope, you have the ability to directly access the variable "foo" from a different thread/process, which is not really implementable.</div><div> </div><div><br></div><div>-atw</div></div>
<br>