[webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table

[Luke Kenneth Casson Leighton]

https://bugs.webkit.org/show_bug.cgi?id=21598

copy of the bugreport is here:

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).

so - with that in mind: explanation :)

quite simple: total independence from "ports".  that's what a good
library offers.   _really_ good libraries can actually be dlopen()ed
on the _one_ function which gets the vector table - this technique was
deployed extensively in samba TNG, and _really_ extensively in an
obscure little project i did in 2000, called xmlvl - an xml-based
programming language [put me off using xml for life, that did :) ]

so, without recompiling the whole of webkit, developers would be able
to write their own "port" of webkit.  actually, you'd be able to drop
the word "port" entirely, and even split out the QWebKit code,
WebkitGTK code etc. into separate libraries or entirely remove them
from webkit altogether, with the expectation that separate projects
would take up the "joining" code (Webkit/qt/* and Webkit/gtk/* etc).

what can you do once this is done?

1) you could make lynx utilise webkit!!!  lynx would get javascript
execution :)  all that lynx would have to do is provide its own vector
table of functions :)  btw, not many people are aware that lynx has a
svgalib port and an X-lib port, but it does.  that would make lynx a
proper web browser!  woo-hoo!

2) you could make a "daemon" out of webkit.  a headless webkit (ooer).
 a search-engine "executor" which could _properly_ execute javascript
on a page (a bit like DumpRenderTree, only doing it properly, and
allowing developers to print out the full HTML web page) and thus be
able to pass the *TRUE* content to the search engine.

3) you can make the bindings (e.g. the webkit-glib bindings) FULLY
independent of the "port" under which they operate.  so, the python
bindings which are at present "hacked" on top of pywebkitgtk
become.... fully independent: they'd be called... ohhh... i dunno...
pywebkit-glib or something.

and THEN - crucially... absolutely absolutely crucially,
python-qwebkit would AUTOMATICALLY get python bindings to the DOM
model, without having to do tons and tons of unnecessary work adding
YET ANOTHER set of bindings (python or qobject / qt) to webkit, to
maintain.

and, the webkit-glib-dom-mm c++ bindings would equally be
"independent" of gtk, qt, wxWidgets etc. etc. etc.  and every other
programming language.

3) you could make a "web scraper" - like pykhtml - out of webkit.

this is a really straightforward, simple and small amount of work, for
a very very large strategic payoff, that increases the usefulness,
power, flexibility and reach of webkit.

l.