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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
