On Mon, Nov 30, 2009 at 2:30 PM, Alexey Proskuryakov <a...@webkit.org> wrote:
> > On 30.11.2009, at 14:05, Dmitry Titov wrote: > > That also pretty much means if we won't have SharedScript, we'll need to >> explore other opportunities toward efficient sharing of code and data which >> does not make people to write a multithreaded UI as SharedWorker solution >> would do. We have practically zero positive response to SharedWorkers being >> used this way. Granted, this is "just one company" but the devs here are >> good and came from variosu other companies so the limited unscientific poll >> kind of shows the outcome... >> > > This makes me wonder if there is any positive experience using > SharedWorkers for this elsewhere - or any better use cases for it. > > At the moment, it seems that technical issues around shared workers's > implementation in WebKit haven't all been resolved yet, and that > GlobalObject could be a better replacement for the same use case anyway. > Dropping one for another is in the spirit of successful experimentation - > what do you think? > > - WBR, Alexey Proskuryakov > > Just a note: In Chrome, a SharedWorker is reachable from any WebKit process, whereas a SharedScript would only be reachable within a WebKit process. This is an interesting distinction, and I can imagine some use cases for SharedWorker that SharedScript could not address. (This distinction arises because we did not want to build a script proxy between WebKit processes as that would be quite costly.) For example, suppose you wanted to have only one instance of a web app responsible for manipulating a database or communicating with a server. There's no guarantee that multiple instances of a web app would all run in the same WebKit process. -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
