[webkit-dev] GlobalScript in WebKit

[Maciej Stachowiak]

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 <dimich at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/93c91a21/attachment.html>