Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
Paul Pedriana-3 wrote: > > While a COM or similar interface may result in a library which makes > porting easiest for new platforms, it sometimes can be harder to > develop and maintain. We've been there and I can say that in some cases > an earlier reply mentioned also that the idea i suggested is "COM-like", and, thus, if that is _believed_, then yes, absolutely, it will be found to be a complete nightmare. background: COM is an object-orientated layer that allows you to define objects. the COM part of Common Object Model is incredibly similar to what GLib / GObjects have become (right down to the horrible c macros, the object refcounting, the interfaces, the object inheritance, everything). COM is a stripped-down version of DCOM (distributed COM) where the much-hated windows 95 team got a hold of the much-better-trained windows nt team's code, and ripped it to shreds. what the windows 95 team took out was the D - DCE/RPC. DCE/RPC is a "functional-programming" style RPC system (and is a perfect candidate for building object-orientated technology, such as DCOM, on top of it). it is _this_ technology that is *purely* c-based and is RPC middleware, and it's unbelievably brilliant beyond belief. in DCE/RPC, there is support for "interface versioning", where each interface can have a single 16-bit number - a "version" - associated with it. servers are expected to support all versions of interfaces, and thus you can upgrade the servers first, and the clients last. so, to cut a long story short, when the earlier poster said "yes, you're suggesting that we implement a cut-down version of COM" - no, not exactly, but close. all you do is shove a 16-bit number at the beginning of the struct, that says "version 1". that's all. _definitely_ not "drag in all the object inheritance, ref-counting". _god_ no. :) -- View this message in context: http://www.nabble.com/webkit-core-need-to-be-cleanly-separated-from-%22ports%22%2C-behind-a-vector-table-tp19982522p20167648.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
While a COM or similar interface may result in a library which makes
porting easiest for new platforms, it sometimes can be harder to
develop and maintain. We've been there and I can say that in some cases
a COM-like interface really is nice to work with; and in other cases it
is perhaps too problematic to maintain. The Mozilla people initially
went a little overboard with this and decided it would be better to
scale it back somewhat.
For me, while it would be nice if everything could fit into a plug-in
interface, in the short run I would be happy if platform-specific
functionality was sometimes handled less by ifdefs within the code and
more via some kind of platform or environment abstraction. Here's an
example; in _javascript_Core/kjs/Shell.cpp there is this:
void StopWatch::start()
{
#if PLATFORM(QT)
QDateTime t = QDateTime::currentDateTime();
m_startTime = t.toTime_t() * 1000 + t.time().msec();
#elif PLATFORM(WIN_OS)
m_startTime = timeGetTime();
#else
gettimeofday(&m_startTime, 0);
#endif
}
For me to add a new platform I need to edit this file and do an
integration whenever the devline WebKit version of it changes. It would
be nice if the code instead looked like this:
void StopWatch::start()
{
m_startTime = platformTimeMs(); // The back-end of this is
specified per platform.
}
Yes you could call platformTimeMs() via a function table or COM
interface, but for a lot of people it would suffice if it was simply
implemented in a platform-specific source directory.
Paul
On Wed, Oct 15, 2008 at 12:04 PM, lkcl <[EMAIL PROTECTED]> wrote:
what is there about, for example, the apache2 vector table system,
where you fill in 28 or so functions in a vector table and hand it back
to the apache runtime, that makes refactoring and redesign difficult?
extensions to the table can be done by having a union of structs,
with an int at the beginning of the table saying "i'm a version 1"
or "i'm a version 2".
then, if you have a "version 1"-using-port that connects to a "version 2"
library, the extra functions that differ from version 1 and 2 will be NULL;
the version 2 webkit library will go "oh, these are NULL, so we're not
providing version 2 functionality".
You seem to be reinventing COM.
While there are certainly parts of WebCore and WebKit as a whole where
some well-chosen interfaces would indeed make it easier to develop and
maintain additional platforms and extensions (example: dave hyatt's
recent refactoring of ScrollView and friends), I'm not sure that a
large C-style vector of function pointers for all of WebKit is an
effective way to accomplish this.
far from making it _more_ difficult to do a redesign, such techniques
would make it _easier_ i believe.
Do you have a proof of concept? Comparing approaches is always easier
with a concrete example than with abstract descriptions.
If nothing else, that would help validate your assertion that it would
be easy to implement this way :-).
Amanda Walker
[EMAIL PROTECTED]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
On Wed, Oct 15, 2008 at 12:04 PM, lkcl <[EMAIL PROTECTED]> wrote: > what is there about, for example, the apache2 vector table system, > where you fill in 28 or so functions in a vector table and hand it back > to the apache runtime, that makes refactoring and redesign difficult? > > extensions to the table can be done by having a union of structs, > with an int at the beginning of the table saying "i'm a version 1" > or "i'm a version 2". > > then, if you have a "version 1"-using-port that connects to a "version 2" > library, the extra functions that differ from version 1 and 2 will be NULL; > the version 2 webkit library will go "oh, these are NULL, so we're not > providing version 2 functionality". You seem to be reinventing COM. While there are certainly parts of WebCore and WebKit as a whole where some well-chosen interfaces would indeed make it easier to develop and maintain additional platforms and extensions (example: dave hyatt's recent refactoring of ScrollView and friends), I'm not sure that a large C-style vector of function pointers for all of WebKit is an effective way to accomplish this. > far from making it _more_ difficult to do a redesign, such techniques > would make it _easier_ i believe. Do you have a proof of concept? Comparing approaches is always easier with a concrete example than with abstract descriptions. If nothing else, that would help validate your assertion that it would be easy to implement this way :-). Amanda Walker [EMAIL PROTECTED] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
Gustavo Noronha Silva-5 wrote: > > On Wed, 2008-10-15 at 08:04 +, Luke Kenneth Casson Leighton wrote: > > While I agree that it would be nice to have a separate library to which > both the GTK+ and Qt ports could link, for instance, I believe this > model would somewhat remove the agility the project has of refactoring > and redesigning big parts of the code. API stability would be something > to worry not only for the most outern layer (the port), and that would > complicate matters. > > gustavo, thanks for responding. question: how so? [would it remove agility for refactoring and redesigning]? what is there about, for example, the apache2 vector table system, where you fill in 28 or so functions in a vector table and hand it back to the apache runtime, that makes refactoring and redesign difficult? extensions to the table can be done by having a union of structs, with an int at the beginning of the table saying "i'm a version 1" or "i'm a version 2". then, if you have a "version 1"-using-port that connects to a "version 2" library, the extra functions that differ from version 1 and 2 will be NULL; the version 2 webkit library will go "oh, these are NULL, so we're not providing version 2 functionality". far from making it _more_ difficult to do a redesign, such techniques would make it _easier_ i believe. you could add in refactored functions into the version 2, support both for a while, then, when sufficient time has passed, drop the version 1 functions. and, during the transition period, users would be able to mix-and-match version-1-using apps with version-2 of the webkit library, and not care in the slightest. ... am i missing something? l. -- View this message in context: http://www.nabble.com/webkit-core-need-to-be-cleanly-separated-from-%22ports%22%2C-behind-a-vector-table-tp19982522p19996413.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
On Wed, 2008-10-15 at 08:04 +, Luke Kenneth Casson Leighton wrote: > On Tue, Oct 14, 2008 at 9:47 PM, David Hyatt <[EMAIL PROTECTED]> wrote: > > The term "webkit core" in your subject is very confusing. Do you mean > > WebKit or WebCore? There is platform-specific code in both. > > apologies. > > i mean "whichever bit that you link webkit link against to produce a > gtk port, or a qt port, or a wx port". While I agree that it would be nice to have a separate library to which both the GTK+ and Qt ports could link, for instance, I believe this model would somewhat remove the agility the project has of refactoring and redesigning big parts of the code. API stability would be something to worry not only for the most outern layer (the port), and that would complicate matters. See you, -- Gustavo Noronha Silva <[EMAIL PROTECTED]> GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
On Tue, Oct 14, 2008 at 9:47 PM, David Hyatt <[EMAIL PROTECTED]> wrote: > The term "webkit core" in your subject is very confusing. Do you mean > WebKit or WebCore? There is platform-specific code in both. apologies. i mean "whichever bit that you link webkit link against to produce a gtk port, or a qt port, or a wx port". l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit core need to be cleanly separated from "ports", behind a vector table
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
