[webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
hyatt at apple.com
Tue Oct 14 14:47:21 PDT 2008
The term "webkit core" in your subject is very confusing. Do you mean
WebKit or WebCore? There is platform-specific code in both.
On Oct 14, 2008, at 4:24 PM, Luke Kenneth Casson Leighton wrote:
> 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
> _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
> 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?
> 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).
> 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
> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev