[webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]

[Dmitry Titov]

On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> All that said, Darin, Maciej and I were discussing this on IRC earlier and
> it would seem that simply adding getWindowByName (or some such) would gain a
> very large amount of the behaviour desired in the {Shared,
> Global}Script[Context] concept.
>

Got to the colloquy transcript of this. I think the proposal there is to
implement getWindowByName() and not to have SharedScriptContext object at
all, rather emulate it by passing around a JS object which would be used to
share things. The argument was made that this will reduce the API explosion
and be less work in WebKit.

However, I'd need to understand how the following would work:

- it's not clear how to load script (the code that is supposed to be
shared). The apps today don't just load the whole code in a single <script>,
they split the script code in pieces and use script tag injection or async
XHR + eval. All of that is defined with reliance on underlying global scope
object which can not be relied upon in the proposed case. Unless JS has some
way to introduce a global scope other then default window... It seems that
'eval' method of progressive script loading breaks.

- running a JS method on a shared JS object depends on global scope used in
context of the call. In case of cross-context calls it can be very confusing
for the developers to understand which context is being used, and I think we
have some bugs in this area too (at least there are a few FIXME sprinkled
around). Having a global scope object associated with the shared script
context makes things easier to use and potentially less buggy. Not sure how
much this is the issue though.

- there were already noted issues with timers, XHR, WebSockets, (as well as
Database, Notifications etc) that simply get killed internally when their
native window closes - there is no exceptions thrown or callbacks called.
The JS wrappers that are still alive but zombied remain, but to be able to
write JS code that correctly recovers don't we need to define some behavior
of those things in case their 'native context' dies? I guess the solution is
to host those in SharedWorker, which was already noted as being not always
desirable.

I agree with desire to reduce the new APIs and this is essentially reducing
it to 0. In particular cases we currently have (GMail and Chat windows)
windows are opened via window.open() so technically we don't even need
getWindowByName() to try this approach. But, will it work? Not sure, for the
reasons above.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091201/43b276d8/attachment.html>