On Mon, 30 Nov 2009, Dmitry Titov wrote: > > That also pretty much means if we won't do 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 limited unscientific poll kind of shows the direction...
The pushback on SharedWorkers at Google is because Google teams don't want to rewrite their apps to work with workers -- SharedScript lets them handle some of the cases SharedWorkers would get them, without having to rewrite as much code. However, we should not be basing the platform's progress on transition cost avoidance of one company. Google can afford to rewrite GMail if it comes down to that. It is not in the Web's long term interests for us to design features that are optimised for the transition phase at the cost of the long-term health of the Web. What we should be looking at is what API do teams prefer to work with when starting from scratch, because on the long term that will be the far more common case than transitioning from a legacy codebase. I don't think that our (Google's) response is representative here. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
