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.
As I said in my other message, I actually think a global script with proper DOM access is a good idea in principle, and in my opinion would have been a better design than SharedWorkers (and indeed, given global script, you can implement shared workers yourself). But we have not done a great job of selling it. Can we make a good case for this feature that will get some buy-in from the broader Web standards community?
Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
