Michael Nordman wrote:
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller <pmue...@muellerware.org>wrote:
Can I create additional GlobalScript's from within an existing
GlobalScript?
That's a good question...
(just having fun... oh the tangled web we weave;)
I'm not sure any has thought thru the implications of that, but it's an
interesting idea.
* An obvious complication is life-cycle management. If GlobalScriptA
attaches to GlobalScriptB, when no 'pages' are attached to either, they
should be eligible for destruction.
* Also about tangled webs... what if A attaches to B, and B attaches to A
For completeness, folks interested in this proposal should probably
check out the serverJS Securable Module stuff:
https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
There are similarities, and differences:
- In serverJS, modules are identified with a JavaScript resource,
presumably a single one. In Shared Scopes (what I'm going to call
Global Script from here on in), modules are identified with just a name
and code is loaded through a different path. I like the Shared Scopes
version better, more flexible.
- In serverJS, module loading may need to be done in a careful order so
that "pre-req" modules are loaded before the modules that pre-req them
(ie, require() them). That's because there is code running while the
module is being defined. If we end up having all the shared scopes
available via their name in every shared scope and page that are
attached to each other, I don't think there's a problem. Creating a new
scope is atomic operation, no user-land code runs as a result. No doubt
folks will be writing guarded code to ensure they only load scripts into
a SharedScope once, since the code loading is now a separate issue.
Again, I like the Shared Scopes approach better.
- In serverJS, a module does not export it's global variable to the
client. Instead, when the module code is run, the object which will
eventually be returned from require() is set to the variable "exports"
in the module code. In Shared Scopes, this additional level of
indirection is not available; "global" variables set in code run in the
context of the SharedScope are the properties of the object returned
from the SharedScope accessor. In this case, I prefer the serverJS
style. It makes it clear in the module code what you actually want the
client to have access to. It also lets you hide private variables
inside your own global environment, which is visible to no one. The
same way variables are typically hidden in a function closure today.
Imagine, maybe you won't have da funky function wrappers anymore!
(function(){
... my code here
})();
The load() method is very similar to the worker loadScript() (or whatever)
function. Perhaps we should combine them into one API, that allows sync or
async in a worker, but only allows async in a GlobalScript. Or at least
advises against use of sync.
I think the API I was thinking of with workers is
importScripts(url,url,urls). It seems crazy to have different ways to
do basically the same thing, whether you're in a worker or not. There
should probably be one API to "load and run a script", that could be
used sync or async (user controlled just like XHR), with callbacks etc.
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
--
Patrick Mueller - http://muellerware.org
