<br><br><div class="gmail_quote">On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov <span dir="ltr">&lt;<a href="mailto:dimich@google.com">dimich@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 Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller <span dir="ltr">&lt;<a href="mailto:pmuellr@muellerware.org" target="_blank">pmuellr@muellerware.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">var context = new GlobalScript();  // perhaps &#39;webkitGlobalScript&#39; as<br>
experimental feature?<br>
context.onload = function () {...}<br>
context.onerror = function () {...}<br>
context.load(&#39;foo.js&#39;);<br>
</blockquote>
<br></div>
Presumably this script is being loaded asynchronously, hence the callbacks.  But since the GlobalScript() constructor returns the &quot;global&quot; object, probably doesn&#39;t make sense to attach the handlers directly there, but actually on the load request somehow.  </blockquote>

<div><br></div></div><div>Good point. Alternative variant to construction/connection to this object could be something like this:</div><div><br></div><div>window.createGlobalScript(&#39;name&#39;, &#39;foo.js&#39;, function(context) {..}, function(status) {..});</div>

<div><br></div><div>where the name and url pair play the same role as on SharedWorker, and 2 callbacks: one delivers load status/errors, another comes with resolved context when it&#39;s ready. One benefit of this is that &#39;context&#39; does not have to expose the &#39;external&#39; API on it and it is always functional once it&#39;s returned. The syntax in the proposal was motivated by commonality with other APIs, like XHR or window.open - however I agree this doesn&#39;t fit 100% either of them...</div>
</div></blockquote><div><br></div><div>fyi: There&#39;s a seperate thread questioning the utility of the &#39;name&#39; parameter in the SharedWorker API. However the debate ends, it would probably be good to identify shared-workers / global-scripts in a similar fashion.</div>
<div><br></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 class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess I&#39;m wondering if there will be some desire to have pages opt-in to this support, signaling this through an additional API, or like the app-cache&#39;s manifest attribute on the &lt;html&gt; element, something in the DOM; doesn&#39;t seem like we should drag the DOM in here, just mentioned it because I was reminded of the way the opt-in works there.<br>


</blockquote><div><br></div></div></div></blockquote><div><br></div><div>I don&#39;t follow the opt-in desirement? If a page wishes to utilize the GlobalScript feature, it calls the API provided to do so.</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 class="im"><div></div></div><div>It is a good idea indeed to have some sort of static opt-in information, maybe via a feature of app-cache - which could hint the UA to load participating pages (of the same application) into the same process so they could share Global Script. It is still impossible (and probably not important) to guarantee a singularity of the Global Script (as in case of cross-domain iframes) but it&#39;d be a good optimization for a multi-process UA.</div>
</div></blockquote><div><br></div><div>I understand the desire for early warning that a page *may* want to utilized a GlobalScript. A &#39;hint&#39; could be useful to a multi-process UA. It&#39;s not clear to me that this is what Patrick was referring to... Patrick?</div>
<div><br></div><div>And I&#39;ll just throw out there that a &#39;hint&#39; in an custom HTTP header of the page&#39;s response would be the earliest warning we could get without static config info present in the UA. I know Ian doesn&#39;t like relying on out-of-band HTTP things for the HTML5 spec... just sayin...</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></div>
<div><br></div><div>Dmitry</div><div> </div></div>
</blockquote></div><br>