On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <i...@hixie.ch> wrote: > 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. > > Presenting this as a SharedWorker vs SharedScript thing is a false dichotomy. SharedWorkers and SharedScript serve different purposes for the people who want to use each.
The majority of applications are not written to do *all* of their logic in a background thread, so it is odd to me that it is espoused as the right paradigm on web developers. There is a certain amount of logic that makes sense to happen on the main thread and be shared across windows. > 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. > On the other hand, just because there is a hammer, it doesn't mean that everything is a nail no matter how much we want it to be. > What we should be looking at is what API do teams prefer to work with when > starting from scratch, And it makes a lot of sense for new apps to do some logic that is quick on the main thread (and not proxy it off to another thread). > 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. > > Based on my 10+ years of experience as an app developer, I think the response is very representative of what I'd want. dave
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev