[webkit-dev] Cleaning House
ggaren at apple.com
Fri Apr 5 09:24:59 PDT 2013
> 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
> 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
> there are people who use WebKit *without* JSC."
Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings.
>> 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.
I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully.
>> 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
> 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.
I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings?
The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure.
Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today.
More information about the webkit-dev