[webkit-dev] GlobalScript in WebKit
jorlow at chromium.org
Mon Nov 30 16:35:30 PST 2009
On Mon, Nov 30, 2009 at 4:29 PM, David Levin <levin at google.com> wrote:
> On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson <ian at 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.
To be fair, app developers in general want to do everything synchronously
but we (in standards land) have pushed back very hard because software
research has shown that such interfaces are very difficult (if not
impossible) to parallelize. That's why SharedScript sidesteps the issue by
saying there should be no parallelism. Which really is a step backwards.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev