I'm somewhat concerned about GlobalScript too. I am pretty wary of
putting complex features in WebKit if it seems like they will be
rejected by the standards process and become orphan WebKit-only
technologies. Perhaps I am somewhat sensitive about this because it
looks like the SQL Database is heading down that road, but it's too
late now for us to drop it. My impression from WHATWG and from TPAC is
that the web standards community and other browser implementors don't
really buy into the value of this feature, so I think there's good
odds we would end up in the orphan situation.
That's not to say GlobalScript is a bad feature on its own merits. In
fact, a while back, in a meeting with some of the Gears folks before
Chrome was publicly announced, I argued that we should have something
like this (a shared object that all pages from a particular domain
could access, where global state and code could live) *instead* of
SharedWorker, because having a separate thread did not seem essential
to the stated use cases. So I can see some plusses to the GlobalScript
design. But now that SharedWorker is out there and has multiple
implementations, it's much harder to make the case for GlobalScript.
And it seems like people in the Web standards community, and in
particular other browser vendors, are not sold.
I'm worried in particular that we'll end up in a situation with WebKit
of sort of throwing darts at the wall and seeing what sticks, feature-
wise. A scatter-shot approach is not so great, because it can become
very hard to phase out the features that don't get wide traction, if
even only a few sites end up depending on them, and even if their use
is conditional.
Now, sometimes a new idea seems either so hugely valuable or so
trivial and low-cost that we don't care if it ends up a WebKit-only
feature. I'm not sure this is one of those cases.
Based on this, I agree with Sam's opinion that we should wait and see
how workers (and in particular SharedWorker) play out before we take
up this feature.
Regards,
Maciej
On Nov 25, 2009, at 8:30 PM, Sam Weinig wrote:
Hi Dmitry,
As I have noted to others on the Chrome team, I do not think this is
good idea and I don't think we should have it in WebKit. It adds
extra complexity to WebKit and gives little beyond what is possible
using inter-window communication and SharedWorkers. I think we need
to give more time for large applications to adopt designs around
workers before we reverse course, at which point, we should again
discuss this in the standards community.
-Sam
On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov <dim...@chromium.org>
wrote:
Hi webkit!
I'm starting to work on actual implementation of GlobalScript
experimental API and started to post patches (hopefully in
reviewable portions). There is an uber-bug which has plan of
implementation.
The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with
both JSC and v8 bindings (first with JSC because at the moment JSC
bindings are easier to work with and I'd wish WebKit not to have 1-
engine-only features ever).
I'd be glad to know if there are suggestions, ideas or concerns of
any kind... For example, if there is no interest in JSC bindings, it
can be hard to get them reviewed by someone who knows them well.
It'd be better to know that earlier.
Thanks!
Dmitry
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
