One question about version conflicts and how they might get worse; sorry if it&#39;s already been addressed.  What happens if a user has an old version of an application like Gmail open and then tries to open a new window to the app, after developers have added new features?  I presume the new window is stuck talking to the old version of the SharedScript?<div>
<br></div><div>Version conflicts are obviously already possible (without SharedScripts) if an old application opens a new window and tries to talk to it.  Today, though, it&#39;s at least mostly safe to have a week-old copy of an app open and then load a separate, newer version in a different window.  (I&#39;m doing that right now with Gmail.)  With SharedScripts in place, it seems like either (1) the new version of the app would have to detect the old SharedScript and deal with it or (2) the user would continue to see errors until he reloaded all the open app windows to get the new version.  And would reloading be sufficient, or would he have to close all the app windows to make the SharedScript go away?</div>
<div><br></div><div>Basically, SharedScripts make multiple windows more dependent on each other.  There&#39;s a lot of benefits to that, though it could also make problems like version conflicts more common.  Have there been any thoughts on ways to address this, or should it be left to web developers?  (I didn&#39;t see anything in the design doc.)</div>
<div><br></div><div>Charlie</div><div><br></div><div><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 9:33 AM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com">atwilson@google.com</a>&gt;</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">On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson <span dir="ltr">&lt;<a href="mailto:mpd@google.com" target="_blank">mpd@google.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote">

<div><br></div><div>A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. Today each window would have to show a notification. That one just occurred to me, I&#39;m sure we can come up with others. </div>



<div><br></div><font color="#888888"><div>Michael</div></font></div></blockquote><div><br></div></div><div>FWIW, we&#39;ve been pushing developers to use SharedWorkers to manage their notifications for exactly this reason. It&#39;s fairly trivial to do so, since notifications are fundamentally an async API anyway. But agreed that SharedScript would also work for this.</div>

<div><br></div><div>-atw</div><div><div></div><div class="h5"><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><div></div><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div></div><font color="#888888"><div>

 - Maciej</div></font><div><div></div><div><div><br><blockquote type="cite"> <div><br></div><div>I sense that there&#39;s some pushback due to a Google property requesting a feature that Google engineers are trying to get into the browser, but I think that Gmail is emblematic of all large web apps. Shared workers have their place, but that place is not sharing the UI code for large apps. </div>



 <div><br></div><div>I saw a comment that forcing multiple windows of one application into the same process is undesirable. I disagree. Gmail is not a CPU-bound application. We believe that the savings of having one JS heap, one request queue, one data store, etc. would outweigh the benefits of process isolation. </div>



 <div><br></div><div>3) Should SharedScript be added to WebKit?</div><div><br></div><div>I&#39;m not a WebKit developer, so I&#39;m not as qualified to comment. However, I believe that SharedScript is a feature that many apps would use. We tried to come up with a representative set of examples in the spec. We&#39;re happy to come up with more. I don&#39;t believe that SharedWorkers will solve those scenarios. I doubt that developers inside or outside of Google will move to a totally async programming model. </div>



 <div><br></div><div>Sorry that this initial mail is also a little scattered. I&#39;ll try to stay on top of the conversation as it progresses, and will hopefully be able to provide a perspective from the trenches of web development.</div>



 <div><br></div><div>Michael</div><div><br></div><div><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 6:16 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:<br>



 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Following up, I think this highlights the distinct set of use cases that shared workers and shared script address:<div>



 <br></div><div>SharedWorkers are a great platform for when you have a single database that is shared across multiple instances of your web app, and you want to coordinate updates to that database. I can imagine sharing a single connection to the server, etc via SharedWorkers.</div>



 <div><br></div><div>SharedScripts are a good platform for when you want to share data/code (for example, the immense body of Javascript used to implement the Gmail UI) across multiple windows. I can&#39;t speak to whether passing a hidden iframe between windows as was suggested in the other thread would address this use case sufficiently. </div>



 <div><br></div><div>-atw<div><div></div><div><br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:<br>



 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I believe that the offline gmail team uses the Gears flavor of shared workers and is planning to migrate to the HTML5 version once DB access is supported from within worker context in shipping browsers.<div>



<br></div><div> So I guess that Gmail would be a candidate app that has asked for both.<br><div><br></div><div>-atw<div><div></div><div><br><br><div class="gmail_quote">On Mon, Nov 30, 2009 at 6:08 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br>



 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br> On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:<br> <br> </div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



 I don&#39;t think it&#39;s correct to say that SharedWorkers are not useful and &quot;we need a SharedScript instead&quot;. They are different things and can address different use cases. For example, SharedWorker is great to make sure there is only one &#39;app instance&#39; running - exactly because it is shared inter-process, it can be used as a &quot;inter-process synchronization primitive&quot; to control how many app instances are opened. SharedScript is a container for data and code shared between pages that comprise a &quot;web application&quot; and normally run in the same process. As in native apps, whether or not multiple instances of the app can run at the same time depends on the author of the app, and can be done either way.<br>



 </blockquote> <br></div> Are there any Web apps at Google or elsewhere currently using SharedWorker? Would any of them still use it if they could switch to SharedScript? Has any app team specifically requested support for *both* SharedWorker *and* SharedScript? (Serious questions, since the justification for SharedScript is largely based on Web developer feedback.)<br>



 <br> Note: if SharedScript was really globally shared it could be used to implement shared workers - simply have the SharedScript manage the per-app Workers.<br> <br> Regards,<br><font color="#888888"> Maciej</font><div>



<div></div><div><br> <br> _______________________________________________<br> webkit-dev mailing list<br> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>



 </div></div></blockquote></div><br></div></div></div></div> </blockquote></div><br></div></div></div> <br>_______________________________________________<br> webkit-dev mailing list<br> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>



 <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br> <br></blockquote></div><br></div> _______________________________________________<br>



webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br><a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>



</blockquote></div><br></div></div></div></blockquote></div></div></div><br>
</blockquote></div></div></div><br>
<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br></div>