<br><br><div class="gmail_quote">On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson <span dir="ltr"><<a href="mailto:mikewse@hotmail.com">mikewse@hotmail.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="im"><br></div>
Maybe I'm mistaken, but I think Drew wanted handling of<br>
"live" objects, where each window gets access to the same<br>
concrete objects (possibly protected by private proxy<br>
objects) so the graph can be walked without cloning.</blockquote><div><br></div><div>To be honest, I'm not really a good spokesperson for this issue, as most of my thinking has been around shared workers which have all the same drawbacks for data sharing that WebStorage has.</div>
<div><br></div><div>I was just saying that I understand the problem that the shared context is trying to address. I personally think that part of the problem can be overcome using the existing tools, although with more effort on the app side than a simple shared context solution.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Drew: are you thinking that the same object graph also<br>
makes up the data cache between sessions? If not, then<br>
persistence is not a must-have for this use case so the<br>
area of ideas could well expand outside webstorage.</blockquote><div><br></div><div>I think ideally serialization would happen only when data needs to be persisted. If I have a data structure that I want to share with other open windows, I shouldn't have to persist it to accomplish this, and I certainly shouldn't have to re-serialize it every time I want to make a minor change.</div>
<div><br></div><div>But, again, I'm just speaking in the abstract - the folks proposing shared context (Dmitry) should probably chime in here as they've thought about this problem much more than I have.</div><div>
<br></div><div>-atw</div></div><br>