[webkit-dev] GlobalScript in WebKit

[Jeremy Orlow]

On Mon, Nov 30, 2009 at 1:45 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov 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.
>>
>
> WebKit (or at least the mainline) is not necessarily a great place for
> experiments. As our Project Goals say: "WebKit is an engineering project,
> not a science project." <http://webkit.org/projects/goals.html>. Of
> course, that's a pretty fuzzy line, because sometimes a use case is really
> well proven and we're not willing to wait for standards groups to get their
> butt in gear. But there are some potential bad scenarios with building
> features that don't have a clear path to standardization:
>
> 1) It will be rejected by other browser vendors and end up a WebKit-only
> (or nearly WebKit-only) feature, but enough WebKit-specific content depends
> on it that we can't drop it, even if we would like to. Then we are stuck
> maintaining a dead-end technology indefinitely. It seems like the SQL
> database may be on this path.
>
> 2) It will get adopted into standards, but with significant changes when
> other implementors and standards experts jump on the bandwagon. These
> changes can cause a very painful transition, since we need to remain
> compatible with legacy WebKit-specific content, yet at the same time we
> don't want to be in violation of the consensus spec. This actually happened
> with <canvas> - it changed incompatibly in ways that broke a bunch of
> WebKit-specific content (in particular Dashboard widgets), but we had to
> implement the standard to support content coded to Firefox. This really
> sucked and we have Dashboard-specific hacks still lying around in our code
> base as a result.
>
> So please realize, experimenting is not free. The cost can be much greater
> than the implementation cost, and may indeed last far beyond the
> experimental era. These kinds of bad scenarios are the reason that nowadays
> we try to get standards buy-in on new Web platform features *before* they
> get shipped in a mass-market product. And experience with these kinds of
> scenarios is what makes some of us very wary of going hog-wild with
> experiments in the WebKit code base. We take backwards compatibility for Web
> content very seriously, and so we hesitate to put anything in that we don't
> feel we can commit to.
>

Isn't it being developed behind a flag?  If not, couldn't it be?  That would
keep it from being inadvertently shipped with any platforms.  If there is
a compatibility breaking burden, it would be those who explicitly choose to
ship it, and those alone.

As far as I can tell, the only thing at issue here is the
code maintenance burden.  Other embedders of WebKit should be shielded from
the other issues you cite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/624674b1/attachment.html>