After some internal discussions, I've sent a quite updated proposal which includes use cases we've looked at ("Global Script"). We've got some experience of talking with app developers and it seems having a concept of 'application context' or 'global script' is a recurring theme.. The unwanted serialization and asynchronously in places where developers don't wants them (think selecting a pice of text in a web application that allows "split window" view at the document) definitely points that something like a "Shared Worker" but without a thread and with direct DOM access is a good idea which compliments the set of building blocks...<br>
<br><div class="gmail_quote">On Thu, Aug 13, 2009 at 11:53 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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" target="_blank">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><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>
</blockquote></div><br>