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

Paul Pedriana Mon, 20 Oct 2008 17:23:18 -0700

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
[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

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

Reply via email to