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

[lkcl]

Gustavo Noronha Silva-5 wrote:
> 
> On Wed, 2008-10-15 at 08:04 +0000, 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.