On Mon, Nov 30, 2009 at 8:52 PM, Oliver Hunt <[email protected]> wrote:
> > On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote: > > > > On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak <[email protected]> wrote: > >> >> On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote: >> >> Following up, I think this highlights the distinct set of use cases that >> shared workers and shared script address: >> >> SharedWorkers are a great platform for when you have a single database >> that is shared across multiple instances of your web app, and you want to >> coordinate updates to that database. I can imagine sharing a single >> connection to the server, etc via SharedWorkers. >> >> SharedScripts are a good platform for when you want to share data/code >> (for example, the immense body of Javascript used to implement the Gmail UI) >> across multiple windows. I can't speak to whether passing a hidden iframe >> between windows as was suggested in the other thread would address this use >> case sufficiently. >> >> >> Would it be fair to say the goal for SharedScript is just to share code >> and data (to reduce memory use of multiple instances of GMail), and not >> network connections, timers, or other APIs based on async callbacks >> (assuming those either remain per-Window or are in the SharedWorker)? If so, >> then it would pretty much completely be handled by sharing of some arbitrary >> JavaScript object, possibly arranged by SharedWorker. >> >> Sharing an out-of-document HTMLIFrameElement would almost even account for >> timers and the like, except that currently in WebKit a frame's Window does >> not exist and its contents are not loaded if the frame is not rendered. >> > > XHRs also don't work after the frame has been unloaded. > > > I think my primary concern is that the use of _Shared_ or _Global_ in the > name implies behaviour similar to that of SharedWorker, which is not > guaranteed, likewise origin based object lifetime can trivially result in > differences in behaviour between browser (which when coupled with the naming > issue) could easily become a headache for developers. > > It seems that what is really wanted is a Worker context that isn't actually > a separate thread, so avoiding the need for postMessage, and have it be > explicitly instantiated so as to avoid any browser-architecture derived > behavioural differences. eg. > > var mySharedContext = new SharableScriptContext("script to load here?"); > mySharedContext.onload = function() { > doStuff(); > } > // or should it be > // mySharedContext.src = "script to load here?" > > Later on: > function doSomethingCoolThatNeedsANewWindow() { > var win = window.open(...); > win.onload = function() { > win.functionThatTakesScriptContext(mySharedContext); > } > } > > // Note handling the passing of the shared context is entirely developer > defined -- eg. the only spec behaviour is the 'new SharableScriptContext' > everything else is whatever the developers wants > // Note 2: I am truly awful at naming things so these names are mostly > chosen to clarify unambiguously-ish what i believe the goal is > > The downside is that it requires manually passing the context to new > windows, the plus side is that it doesn't provide (or imply) behaviour that > may be ('necessarily') different between UAs. > > --Oliver > > This seems pretty compelling to me. I think if we also had a function like window.getWindowByName(name), then we could support the use case of a newly opened window connecting to an existing window to get access to an existing SharableScriptContext. (To further support sharing from a newly opened window, perhaps it would be interesting if application manifests could be leveraged to identify URLs that should be loaded in the same browsing context.) -Darin
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
