Hi Geoff, First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines.
Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: """ Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. """ So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: "I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC." Now I will try to answer your questions... > [...] > Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. > What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. > Do you see any cost to the WebKit project in maintaining the v8 > bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) > Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. > What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. Thanks, Mario _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
