[webkit-dev] SharedContext (was: GlobalScript in WebKit)

[Patrick Mueller]

Couple of notes:

- the name SharedScriptContext is a big win over GlobalScript - this is 
more about sharing things than making them global, and more about 
contexts than scripts.  It's like if the name SeparateScript was used in 
instead of Worker, or something, just because a script is associated 
with it - though it's not the important bit.  I'd go for the name 
SharedContext to make it even shorter (and I use that name below).

- I've been thinking about how you could use SharedContext as a means of 
implementing CommonJS modules, or something close: see 
http://wiki.commonjs.org/wiki/Modules/1.0 .  I suppose you'd end up 
creating a SharedContext per module.  So I would hope the implementation 
could handle lots of modules.  Java's OSGi module system wasn't 
originally imagined to be used to load 1000's of modules, but is in fact 
doing that today (in Eclipse-based products).  Specifically, where the 
section 1.1 of Worker spec [1] says "workers are expected to be 
long-lived, have a high start-up performance cost, and a high 
per-instance memory cost", I'd expect those "highs" to not be high for 
SharedContext.

In any case, it's interesting to think about users using this facility 
on a massive scale, like they sometimes do with JavaScript itself these 
days.

- It would probably be useful to engage the CommonJS folks who have been 
dealing with some of the same 'shared context' issues as presented in 
this proposal.  I'm not one of them, I've just been lurking there. 
Browsers are the only people using JavaScript these days!

Frankly, I like the CommonJS module system a bit more than this proposal 
as it provides a capability of hiding things in the SharedContext - much 
like you can hide things in a Function context today in JavaScript. 
Actually, it's not that it provides hiding, it's that it requires 
exporting things you want to be visible; same effect.

- Example 1.2.3 of the Worker spec [1] contains a mini use-case for 
SharedContext, specifically the importScripts("io.js").  In this case, 
loading "io.js" into every worker isn't much of a hardship.  But if you 
had to load lots of the same scripts into lots of workers, it would be 
shame to not be able to share the JavaScript code (ie, run-time code, 
not just the cached source).

[1] Worker spec referenced: 
http://www.whatwg.org/specs/web-workers/current-work/ ; the version I'm 
looking at is "Draft Recommendation - 1 December 2009"

-- 
Patrick Mueller - http://muellerware.org