Good day, Zoltan, On Tue, Dec 6, 2011 at 1:23 PM, Zoltan Herczeg <zherc...@inf.u-szeged.hu> wrote: > Hi Anton, > >> Of course, we're doing this because of our work on Dart, but our >> intent was to solicit a feedback from the WebKit community if there is >> any interest in supporting runtimes additional to JS (and not JS + >> Dart) in the first place. > > The question they raised was what we need to sacrifice for this support. > JS is heavily tied with WK internals, lots of JS specific things > everywhere (yeah, you can change the JS engine in WK, but only to another > JS engine). Change that to something general affects maintenance (new > abstraction layers / API) and performance (probably memory as well), and > its drawbacks are unknown yet (and its advantages are questionable), > especially in a mixed environment.
I absolutely share this concern. We really hope (and hopefully patch proves it), that as of now, burden is minimal: outside of bindings, we only touch a handful of stuff: 1) Source/WebCore/dom/ScriptElement.cpp: to tag ScriptSourceCode with mimetype (+10 trivial lines imho) 2) and changes in inspector. AFAIK, some of them are beneficial on its own, while others are more related with devtools support for other languages (Objective-C dev tools anyone :). And no full fledged abstraction levels, just a couple of reasonable (I am biased, I know) interfaces. And we did preliminary experiments on perf impact and found no perf implications for mutli-vm patch by itself. I don't want to say we have no burden, any change has, but if there is a minimal merit in multi-vm support, I believe the burden is minimal enough. > > I think you should start this work in a private branch (code.google.com?) > and tell us your experiences later. It is difficult to judge this feature > at the moment. What would you recommend as a measure of success? Something we can report back and ask if we're ready? We're definitely considering hosting the work in some other place and have no technical difficulties with this. We just want to be as close to the WebKit community as possible. Thanks again for your thoughts, anton. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
