Re: Webkit2 porting

[Jim Nelson <jim yorba org>]

I've been on vacation and so I'm catching up with this thread.

I've looked over Robert's github branches and am still on the fence.  I'm always going to lean toward the "engineered" solution, and at this moment that would be the D-Bus approach.

To respond to some points made in this thread so far:

I agree with Shaun: the WebKit 2 API changes seem geared for web browsers, not the plethora of applications now relying on WebKit.  Someone mentioned improved UI responsiveness and performance with the new model, but again, just as WebKit stability hasn't been a big issue for us, neither is performance.

Let me put it this way: if we were starting Geary *today* and saw how WebKit 2 required us to interact with the rendering process, I would look around for another embedded HTML viewer/editor solution before adopting it.  This change is akin to SQLite moving to a separate-process model: a lot of work on our part for little to no appreciable benefit.

That said, it appears the boat has left the dock, so I'll wrap up my complaints there.

As far as proxying the DOM, I suspect the real performance problems are not in individual operations but operations involving iteration.  (In other words, inserting a single DIV isn't an issue, but walking the tree looking for all DIVs of a certain class is.)  We do iterations in a few places, so we'd have to be cognizant of that.

If WebKitGTK proxied the most-used subset of DOM operations and let the application write its own WebExtension for custom and performance-sensitive operations, that would go a long way toward lessening the collective pain.  Then again, maybe it's only Geary and Evolution that suffer this pain and we should just man up and do the port.

-- Jim