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