Black-box composition of mismatched software components

140 5.6. Migration between support libraries: ephy–webkit
5.6 Migrationbetweensupportlibraries: ephy–webkit
Another area of continuing evolution in contemporary codebases is that of web browsers
and associated software. The Epiphany web browser 6 migrated during 2007–08 from a
singleMozilla-basedHTMLdisplaywidgettoamoreflexiblecodebasesupportingboththe
Mozilla renderer and a Webkit-based one. We compare Epiphany’s internal WebKitEmbed
adaptation layer with a Cake implementation.
The developers of Epiphany chose to strip out the adaptation layer after Webkit migration
was completed, around July 2008, and target Webkit APIs directly. We therefore
used Subversion revision 8300 (28 June 2008) as the reference codebase for Cake reimplementation.
Although there is no relevant discussion of the decision to remove the
abstraction layer, either in the changelogs or mailing list archives, clearly the developers
anticipated no future need to change the target API. Performance could be a plausible
motivation, but the interface in question is not particularly performance-sensitive. More
likely, the change was intended to simplify the codebase, in the assumption (arguably
optimistic) that there would be no future need to support alternative renderers. (This
highlights the anticipation difficulties surrounding abstraction layers, as we remarked in
§1.2.2.)
The adaptation logic we reimplemented is effectively circumscribed by the definition
of class WebKitEmbed. For simplicity, we left as is some additional adaptation code handling
cookie management, password management and certain other functionality, since
this contained only no-op implementations in our chosen revision. Similarly, we retained
the utility classes WebKitEmbedPrefs and WebKitEmbedHistoryItem for use by our adaptation
logic; these could be implemented in Cake, but owing to their small size, their C
code is dominated by boilerplate, so would not give useful measurements. A particular
complication with this boilerplate is that it is derived from the GObject library on which
Epiphany is based, and is generated by heavy use of C preprocessing; we discuss this in
the next subsection.
5.6.1 Objects, associations and their construction
Epiphany uses subclassing (using the GObject library [Krause 2007]) to connect an Embed
object with a Webkit instance: the subclass’s fields point to Webkit resources. In
Cake we use an association: the Embed object is associated with the relevant Webkit objects.
Recall that this is implemented using an aggregate umbrella object, as described in
§2.3.4. In the Cake implementation of the adapter, the umbrella object’s additional fields
accommodate the state which was added by subclassing in the original implementation.
Contrast the Cake fragment of Fig. 5.15 with the C fragment of Fig. 5.16.
In the C case, a WebKitEmbed object is a EphyBaseEmbed and has a WebKitWebView,
an EphyHistory and some other state. In the Cake version we factor this slightly differently:
a given EphyBaseEmbed and EphyHistory are associated with a WebKitWebView. “Is
associated with” is effectively the same as a has-a relationship, as conventionally encoded
by a stored pointer. However, in our Cake code this is encoded not by directly embedding
6 http://www.gnome.org/projects/epiphany/