[webkit-dev] GlobalScript in WebKit

[Michael Nordman]

http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
What a great rant :)

I'm also reminded of this quote...
"The reasonable man adapts himself to the world. The unreasonable man
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." -George Bernard
Shaw<http://en.wikipedia.org/wiki/George_Bernard_Shaw>

The Chrome team has come around to putting this particular feature into
Chrome as an experiment. It's not clear that can be pulled off without
actually putting some bits into WebKit, and I think we're of the opinion
that the cleanest implementation is to have the code reside entirely in
WebKit. (Personally, I think to do otherwise puts us into the realm of
hackery  to pull off the experiment.)

Sam said "It adds extra complexity to WebKit". We can and should keep a
careful eye to minimize that.


On Mon, Nov 30, 2009 at 9:55 AM, Dimitri Glazkov <dglazkov at chromium.org>wrote:

> Reading this, I am reminded of a great commentary by Alex Russell,
> written nearly 3 years ago:
>
> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
>
> Despite of what I may think about SharedScript, I am certain that
> waiting -- whether for standards community or Web developers to
> embrace or reject our ideas -- is not the right answer. If we really
> want to move the Web platform forward, we can't afford a feedback
> cycle this long. Especially, when we have an opportunity for close
> collaboration with Web developers of some of the most JS-intensive Web
> properties.
>
> Experimenting is great. We should experiment.
>
> This doesn't mean we shouldn't discuss technical merits of the
> proposed solution, including more efficient ways of accomplishing the
> same thing.
>
> :DG<
>
> On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov <dimich at chromium.org> wrote:
> > What I meant was it would be nice, for the sake of discussion, to share
> the
> > experience of real life applications that used SharedWorkers or
> inter-window
> > communications for sharing of significant portions of code and data.
> Google
> > apps may be a partial example but it is a real life example of concrete
> > issues with proposed solution that sounds pretty generic and useful for
> > other web apps. It is only prudent to take their feedback rather then
> > replace it with our own theories about future of the web. No doubt this
> is a
> > new mechanism and it's good to question it, since it has costs even as
> > experimental API. Gut feelings vary, some app devs say they need it to
> solve
> > real issues, we dont hear from other app devs who were facing similar
> issues
> > and solved it differently. Seems there is no strong argument to kill it
> nor
> > bless it. Why don't make it experimental and see? If it was possible to
> > implement it in extension or plugin, we would run it as another
> Gears-like
> > experiment, but it can not be done in a plugin... I believe there could
> be
> > good arguments that simply didn't surface yet, and hope to hear them.
> > Dmitry.
> >
> > On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting <pkasting at google.com>
> wrote:
> >>
> >> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov <dimich at chromium.org>
> wrote:
> >>>
> >>> BTW, could you tell what's the 'course' that would be reverted?
> >>
> >> Meaning, "before we decide that SharedWorkers and inter-window
> >> communication are insufficient, and a further proposal should be
> entertained
> >> by the standards community".
> >> PK
> >
> > _______________________________________________
> > 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/71673801/attachment.html>