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

[David Hyatt]

The term "webkit core" in your subject is very confusing.  Do you mean  
WebKit or WebCore?  There is platform-specific code in both.

dave

On Oct 14, 2008, at 4:24 PM, Luke Kenneth Casson Leighton wrote:

> 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.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev