Bug 21598 – webkit core need to be cleanly separated from "ports", behind a vector table

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit API

[Luke Kenneth Casson Leighton]

vector tables.

a c struct containing pointers to higher order functions.  used extensively in FreeDCE, linux kernel and the NT 4.0 kernel (e.g. the Lsa Security).

good library interfaces are _so_ divorced from other libraries that they don't even access "standard" c or c++ libraries.  evvverry single function - of everything that they need - goes into the vector table.

in the case of kernels, you don't have any choice but to do that.  in FreeDCE, it was just good practice.

for webkit, it's a little insane to do a complete redesign of the library, _but_ - a good starting point would be the boundary between the ports and the webkit core (with the second stage being to _not_ call direct HTTP access for XMLHTTPRequest, but to call out to the functions in the vector table, to perform the URL data fetching.  that would be _extremely_ useful).

basically, the interface would look _incredibly_ similar to what webkitwebview.cpp looks like at the moment.  except that you'd go via a vector table, and the initialisation would involve setting some 80 functions.

_really_ good library design has ONE public function - ONE!  and it's the function which returns you a pointer to the vector table, for the "port" developers to fill in all of the higher order function pointers.

the advantages of taking this approach will be explained on the mailing list.

the amount of actual work required to be done is really quite remarkably small, and would in many ways be quite simple and non-challenging (always nice to have something _simple_ to do which offers quite a lot of advantages).

[Anders Carlsson]

The benefit of this would not outweigh the massive amount of work it would be + the inevitable performance regression of using indirect function calls everywhere.