Previous branches have been used to bring up interestingly complicated features, or features that had the potential to cause dramatic stability issues during their early work (such as the old svg-experimental branch). This project appear to be largely a make work project as it's already possible to have bindings for multiple languages (as the C++, GLib, ObjC, V8 and JSC bindings demonstrate).
It seems an academic exercise to see if we can create a general architecture to make more bindings, as is exporting support for proprietary extensions like vbscript, python or dart to the web. As the 90s demonstrated such "features" are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road, even in the cases where the overall result was a "good" thing -- such as canvas - for the subsequent standardisation caused us quite a bit of compatibility problems, even though it was a very compact and contained api. --Oliver On Dec 5, 2011, at 6:09 PM, Ryosuke Niwa wrote: > I agree with Peter here. It appears to me that having a WebKit branch to > experiment a new feature will help us making an informed decision as to > whether we want to accept patches or not for the feature better than looking > at two giant patches posted on chromium.org. > > Preferably, Vijay also file a bug and possibly post a patch on > bugs.webkit.org. > > - Ryosuke > > On Mon, Dec 5, 2011 at 5:39 PM, Peter Kasting <pkast...@chromium.org> wrote: > On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen <gga...@apple.com> wrote: > > We're creating a branch in order to demonstrate that it's useful and that > > it does not negatively impact hackability or performance. > > It hadn't occurred to me to view the goals of the WebKit project as applying > only to trunk, and not to branches. I'd be interested in hearing from other > WebKit engineers: Do you think that the goals of the WebKit project apply to > trunk alone, or to branches as well? > > It sounds from the quote above like Vijay is not trying to change what the > goals are, only to obtain an environment where it's possible to demonstrate, > by practical experience, that some set of changes is indeed consistent with > WebKit's goals. In principle a branch seems appropriate for that to me > unless there is widespread agreement that the entire idea of these patches is > so contrary to what we want that no one should have ever even thought about > doing them in the first place. I'm not sure things are that clear-cut, so > seeing a more fleshed-out system might be useful. > > PK > > _______________________________________________ > 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
