A Reference Architecture for Web Browsers

Alan Grosskurth and Michael W. Godfrey

Software Architecture Group (SWAG)
School of Computer Science
University of Waterloo
Waterloo, ON N2L 3G1 CANADA
{agrossku,migod}@uwaterloo.ca

Abstract systems, no reference architecture has been proposed yet for

web browsers.
A reference architecture for a domain captures the fun- The web browser is perhaps the most widely-used soft-
damental subsystems common to systems of that domain as ware application in history. Although the domain is only
well as the relationships between these subsystems. Hav- fifteen years old, it has evolved significantly over that time.
ing a reference architecture available can aid both during It provides business and home users with convenient access
maintenance and at design time: it can improve understand- to a wealth of information and services. Internet-enabled
ing of a given system, it can aid in analyzing trade-offs be- commerce currently accounts for billions of dollars worth
tween different design options, and it can serve as a tem- of annual sales and is constantly growing.
plate for designing new systems and re-engineering existing The requirements for web browsers can differ signif-
ones. icantly depending on the needs of the intended users.
In this paper, we examine the history of the web browser For example, handheld computer users typically want fast
domain and identify several underlying phenomena that browsers with small memory footprints and streamlined
have contributed to its evolution. We develop a reference ar- user interfaces, while desktop users are often willing to
chitecture for web browsers based on two well known open trade-off some efficiency for additional features such as
source implementations, and we validate it against two ad- support for multiple languages. Additionally, web standards
ditional implementations. Finally, we discuss our obser- are constantly evolving, putting pressure on browsers to add
vations about this domain and its evolutionary history; in support for the latest specifications. A reference architec-
particular, we note that the significant reuse of open source ture for web browsers can help implementors to understand
components among different browsers and the emergence of trade-offs when designing new systems, and can also assist
extensive web standards have caused the browsers to exhibit maintainers in understanding legacy code.
“convergent evolution.” In this paper, we derive a reference architecture for web
browsers from the source code of two existing open source
Keywords: Software architecture, reference architec- systems and validate our findings against two additional
ture, software evolution, component reuse, web browser. systems. We explain how the evolutionary history of the
web browser domain has influenced this reference architec-
ture, and we identify underlying phenomena that can help
1 Introduction to explain current trends. Although we present these ob-
servations in the context of web browsers, we believe many
A reference architecture[27] for a domain captures the of our findings represent more general evolutionary patterns
fundamental subsystems and relationships that are common which apply to other domains.
to the existing systems in that domain. It aids in the under- This paper is organized as follows: Section 2 provides an
standing of these systems, some of which may not have their overview of the web browser domain, outlining its history
own specific architectural document. It also serve as a tem- and evolution. Section 3 describes the process and tools we
plate for designing new systems, identifying areas in which used to develop a reference architecture for web browsers
reuse can occur, both at the design level and the implemen- based on the source code of two existing open source sys-
tation level. While reference architectures exist for many tems. Section 4 presents this reference architecture and ex-
mature software domains, such as compilers and operating plains how it represents the commonalities of the two sys-
tems from which it was derived. Section 5 provides valida- Lynx
1992 1.0 Legend
tion for our reference architecture by showing how it maps Open−source

onto the conceptual architectures of two other systems. Sec- 1993 Closed−source
2.0 Mosaic
tion 6 discusses related work, and Section 7 presents con- 1994
1.0 Hybrid
Internet
clusions. Explorer Netscape
1995 1.0 W3C founded
2.4 1.0 2.0
2 The Web Browser Domain 1996 2.0 2.0
Opera
2.1
3.0 3.0
1997 3.0 3.0
2.1 Overview 4.0
4.0 Mozilla
1998 1998−03−31
Konqueror
The World Wide Web (WWW) is a shared information 4.5 1.0
1999 5.0
system operating on top of the Internet. It consists of doc-
uments, as well as other types of files such as images and 2000
video clips, which are transmitted via HyperText Transfer 5.5 6.0 M18 2.0 4.0
2001 5.0
Protocol (HTTP), a stateless and anonymous means of in-
Galeon 6.0
formation exchange. A web browser is a program that re- 6.0 1.0
2002
trieves these documents from remote servers and displays 7.0 1.0 3.0 Safari
1.2 Firefox
them on screen, either within the browser window itself or 2003 0.5 0.8 7.0

by passing the document to an external helper application. 1.0

2004 2.85 1.2
Documents are written using HyperText Markup Language 1.7
(HTML) and contain hyperlinks which point to other places 1.0
2005 8.0 Beta
in the same document, or in different documents. Every
resource on the Web is identified by a unique Uniform Re-
Figure 1. Web Browser Timeline
source Identifier (URI). The web browser presents an in-
terface to the user that allows particular resources to be re-
quested explicitly by URI, or implicitly by following em- hearing loss, and motor impairments.
bedded hyperlinks.
Although HTML itself is a relatively simple language
for encoding web pages, other technologies may be used to 2.2 History and Evolution
improve the visual appearance and user experience. Cas-
cading Style Sheets[4] (CSS) allow authors to add layout The origins of the World Wide Web (WWW) can be
and style information to web pages without complicating traced back to a proposal written by Tim Berners-Lee in
the original structural markup. JavaScript, now standard- 1990 at the European Nuclear Research Center (CERN). A
ized as ECMAScript[7], is a host environment for perform- year later he had written the first web browser, which also
ing client-side computations. Scripting code is embedded served as a simple HTML editor. This browser was text-
within HTML documents, and the corresponding displayed only and it allowed users to browse the web by typing in
page is the result of evaluating the JavaScript code and commmands that referenced numbered links. Around the
applying it to the static HTML constructs. Examples of same time, researchers at the University of Kansas had be-
JavaScript applications include changing element focus, al- gun to work on their own hypertext browser called Lynx in-
tering page and image loading behaviour, and interpreting dependent of the WWW. Lynx was also a text-only browser,
mouse actions. Finally, there are some types of content that but it allowed users to browse documents using navigational
the web browser cannot directly display, such as Macrome- keys, rather than typing in commands. In 1993, Lynx was
dia Flash animations and Java applets. Plugins, small pro- adapted to support the WWW, and it quickly became the
grams that connect with other programs, are used to embed preferred text-only browser. In 1995, it was released under
these types of content in web pages. a free software license. Figure 1 shows when the various
In addition to retrieving and displaying documents, web releases of Lynx occurred, along with the releases of other
browsers typically provide the user with other useful fea- popular browsers.
tures. For example, most browsers keep track of recently Also in 1993, the National Center for Supercomputing
visited web pages and provide a mechanism for “bookmark- Applications (NCSA) released a web browser called Mo-
ing” pages of interest. They may also store commonly en- saic to the Internet community. As one of the first graphi-
tered form values as well as usernames and passwords. Fi- cal browsers for the web, it allowed users to view images
nally, browsers often provide accessibility features to acco- directly interspersed with text, as well as scroll through
modate users with disabilities such as blindness, low vision, large documents. It had an easy point-and-click interface
that set a new standard for web browsers. During the same source desktop for UNIX-like systems, Konqueror is a file
year, the first commercial Internet domain name was reg- manager and universal document viewer as well as a web
istered by Digital Equipment Corporation (DEC). As the browser. In 2002, Apple used the core of Konqueror as
commercial potential for the Internet began to grow, the the basis for their own OS X web browser, Safari. Al-
University of Illinois forked off an offshoot called Spy- though Safari is closed source, Apple has released their
glass to commercialize and support technologies developed changes to the KHTML core engine back to the commu-
at NCSA. Around the same time, the creator of Mosaic, nity as the open source Webcore[23] engine. This code has
Marc Andreeseen, left NCSA to co-found Netscape Com- since been reused in several other OS X browsers, such as
munications Corp. The first version of their Netscape web OmniWeb[18].
browser was released in 1994. Netscape introduced the Finally, Internet Explorer’s closed source core has
notion of continuous document streaming, which allowed been used as the basis for several closed-source Windows
users to view parts of documents as they were being down- browsers: Maxthon[13], Avant[2], and NetCaptor[17] each
loaded, rather than wait for the entire download to finish. provide features not found in IE such as tabbed browsing
Also in 1994, the World Wide Web Consortium (W3C) was and advertisement blocking. More interestingly, version 8
founded to promote interoperability among web technolo- of Netscape’s browser is expected to be based on Firefox
gies. and support IE-based rendering as well as Mozilla-based
In 1995, Microsoft released the Windows 95 operating rendering, allowing the user to switch between the two on
system. They included with it their own web browser, In- the fly. Since there are subtle rendering differences between
ternet Explorer (IE), which was based on code licensed the engines, this feature may be useful because it would al-
from Spyglass. A period known as “browser wars” ensued, low the user to choose the engine which produces the better
characterized by heated competition between Microsoft and results for a particular web site. Additionally, it may bene-
Netscape. During this time, each browser introduced nu- fit web developers who need to test compatibility with both
merous innovations and proprietary enhancements to the engines. However, it can be argued that including two dif-
web in an effort to attract more users. Although Netscape ferent engines undermines the goal of web standards, which
started off with over 90% market, Microsoft eventually took is to ensure web sites function identically across all engines.
over the market, likely because their browser was included
for free with Windows and could not be removed. In 1998, 2.3 Basic Usage
Netscape released most of the source code for the upcoming
version of their browser under the in-house project name, Although web browsers have evolved significantly since
Mozilla. Much of the code was rewritten, and eventually the early days of the web, their basic operation still remains
Mozilla released version 1.0 in 2002, which provided strong relatively simple. A user begins by typing in a URI to view.
support for emerging web standards, such as CSS. Netscape Using HTTP, the browser sends a request to the appropri-
now creates their browser by re-branding particular releases ate remote web server for the document. The document is
of Mozilla and adding in proprietary features. By this time, downloaded onto the user’s computer, and a visual represen-
the closed source browser Opera[19] had also appeared, tation is rendered and displayed on the user’s screen. If the
with its origins tracing back to a research project at the Nor- document contains content other than basic HTML or Ex-
wegian telecom company, Telenor. tensible Markup Language (XML), the browser may open a
Since the rollout of Mozilla, a large number of varia- third-party application to display it. By clicking on hyper-
tions have appeared. While the core of the browser remains links in the document, the user can then navigate to other
the same, these variations offer alternative design decisions related documents, which will be requested and displayed
with respect to user-level features. Mozilla’s emphasis on by the web browser in a similar manner.
cross-platform support sacrifices tight integration with each
particular platform; Galeon[8] remedies this by integrating 3 Deriving a Reference Architecture
with the Gnome Desktop Environment, and Camino[3] with
Apple’s Mac OS X. Mozilla’s complex user interface and Using the source code and available documentation for
integrated mail client make it too cumbersome for some two different web browsers, we derived a reference archi-
tastes; Firefox is a standalone browser developed by the tecture for the web browser domain. This reference archi-
Mozilla Foundation to provide lighter, more streamlined tecture represents the abstract architecture of the domain,
user interface. (In fact, Mozilla has recently been officially and was derived by following a process similar to that which
discontinued in favour of Firefox[15].) is described by Hassan and Holt in [31]:
In addition to Mozilla-based browsers, there are also
several browsers based on Konqueror[10]. Developed for 1. Two mature browser implementations were selected
the K Desktop Environment (KDE), a user-friendly, open from which to derive the reference architecture.
 Source Object Program
code code facts
Build bfx rawlink User Interface

Linked

Data Persistence
Predefined program
Facts with File level facts
landscape decomp− program
schema osition facts
addschema addcontain liftfile Browser Engine
Hierarchichal
Software subsystem
landscape decomposition

Concrete Conceptual
Architecture Architecture Legend Rendering Engine
Tool
Adjustments
jgrok script

Data flow
lsedit JavaScript XML
Human interaction Networking Interpreter Parser Display Backend

Figure 2. Extraction process for concrete ar- Figure 3. Reference architecture for web
chitecture browsers

2. For each brower:

was compiled into binary object code using the standard
(a) A conceptual architecture was proposed based on GNU toolchain. Next, the program facts were extracted us-
domain knowledge and available documentation. ing bfx. The program facts were then linked using a spe-
cialized jgrok script. Since the systems studied were rel-
(b) The concrete architecture was extracted from the
atively large, the relations between the entities were propa-
source code and used to refine the conceptual ar-
gated from the function level to the file level, using another
chitecture.
specialized jgrok script. Next, a hierarchichal subsystem
3. A reference architecture was proposed based on the decomposition was created based on the system’s concep-
common structure of the conceptual architectures. utal architecture. This containment structure was then ap-
plied to the file-level program facts, and a standard schema
4. The reference architecture was validated against other was added to produce the software landscape. This land-
browser implementations. scape respresents a preliminary version of the concrete ar-
chitecture of the system, and it was explored and adjusted
The two implementations chosen to serve as a basis for futher using lsedit to arrive at the final version.
derivation were Mozilla and Konqueror. They were cho- The size of the extraction artifacts was at most within a
sen because they are mature systems, have reasonably large factor of two of the size of the build artifacts, and typically
developer communities and user bases, provide good sup- much smaller. The extraction process was almost entirely
port for web standards, and are entirely open source. Both automated; the only manual tasks were deriving the hier-
Internet Explorer and Opera meet the first three require- achichal subsystem decomposition and adjusting the land-
ments, but were not suitable for examination because they scape in lsedit. If the system was small or the directory
are closed source. structure of the source code corresponded well with the ar-
chitectural structure, these steps did not require much effort.
3.1 Extraction Methodology On the other hand, if the system was large and the architec-
tural structure was not reflected in the directory structure, a
The concrete architecture of each system was extracted significant amount of effort was involved in developing an
from its source code using QLDX[20], a reverse engineer- accurate subsystem decomposition.
ing toolkit developed at the University of Waterloo for ex-
ploring and visualizing software architectures. The toolkit
consists of bfx, a C and C++ fact extractor which operates
4 A Reference Architecture for Web
on binary object files; jgrok, a relational calculator ca- Browsers
pable of manipulating these facts; and lsedit, a tool for
viewing and editing software landscapes. The reference architecture we derived is shown in Fig-
The process used to extract the concrete architecture is ure 3; it comprises eight major subsystems plus the depen-
shown in Figure 2. First, the source code for the system dencies between them:
1. The User Interface subsystem is the layer between the The reader may wonder why we have placed the HTML
user and the Browser Engine. It provides features such parser within the rendering engine subsystem, while isolat-
as toolbars, visual page-load progress, smart down- ing the XML parser in a subsystem of its own. The answer
load handling, preferences, and printing. It may be is because although arguably less important to the function-
integrated with the desktop environment to provide ality of the system, the XML parser is a generic, reusable
browser session management or communication with component with a standard, well-defined interface. This is
other desktop applications. in contrast to the HTML parser, which is often tighly inte-
grated with the rendering engine for performance reasons,
2. The Browser Engine subsystem is an embeddable
and can provide varying levels of support for broken or non-
component that provides a high level interface to the
standard HTML. That is, this design decision seemed to be
Rendering Engine. It loads a given URI and sup-
a common feature of web browser architectures.
ports primitive browsing actions such as forward, back,
and reload. It provides hooks for viewing various as-
pects of the browsing session such as current page load 4.1 Mozilla
progress and JavaScript alerts. It also allows the query-
ing and manipulation of Rendering Engine settings. The Mozilla Suite[16] is one of the most prominent and
widely-used open source projects today. It was started in
3. The Rendering Engine subsystem translates a URI into 1998 when Netscape Communications released the source
a visual representation. It is capable of displaying code for the development version of their popular Netscape
HTML and XML documents, optionally styled with Communicator product on the Internet under a free soft-
CSS, as well as embedded content such as images. It is ware licence. Now, almost seven years later, most of that
responsible for page layout and may contain “reflow” system has been completely redesigned and rewritten, and a
algorithms which incrementally adjust the position of large number of new features have been added. Mozilla was
elements on the page. This subsystem also includes written with several design goals in mind: support for web
the HTML parser. standards as well as broken web pages, support for multiple
4. The Networking subsystem implements file transfer platforms, and fast rendering. We examined version 1.7.3,
protocols such as HTTP and FTP. It translates between which consists of approximately 2,400 kLOC. Most of the
different character sets, and resolves mime types for source code is written in C++ although large parts of the
files. It may include a cache of recently retrieved re- user interface are written in JavaScript and a small amount
sources. of legacy code is written in C. We built and extracted the
Linux version of Mozilla which uses the GTK toolkit.
5. The JavaScript Interpreter evaluates JavaScript (also The mapping of Mozilla’s conceptual architecture onto
known as ECMAScript) code, which may be embed- the reference architecture is shown in Figure 4. We note the
ded in web pages. JavaScript is an object-oriented following observations about Mozilla’s architecture:
scripting language developed by Netscape. Certain
JavaScript functionality, such as the opening of pop- • The User Interface subsystem is split into two subsys-
up windows, may be disabled by the Browser Engine tems: the XPFE toolkit and the actual user interface.
or Rendering Engine for security purposes. The reason for this is that Mozilla reuses the XPFE
6. The XML Parser subsystem parses XML documents toolkit as a basis for the user interfaces of other ap-
into a Document Object Model (DOM) tree. This is plications in the Mozilla suite including the mail/news
one of the most reusable subsystems in the architec- client and the HTML editor.
ture. In fact, almost all browser implementations lever-
• All data persistence is provided by Mozilla’s profile
age an existing XML Parser, rather than rewriting their
mechanism, which is responsible for storing both high-
own from scratch.
level data such as bookmarks and low-level data such
7. The Display Backend subsystem provides drawing and as a page cache.
windowing primitives, a set of user interface widgets,
and a set of fonts. It may be tied closely with the oper- • Mozilla’s Rendering Engine is larger and more com-
ating system. plex than that of other browsers. This is likely because
it contains more functionality; for example, it is re-
8. The Data Persistence subsystem stores various data as- sponsible for rendering the application’s user interface
sociated with the browsing session on disk. This may and well as web pages.
be high level data such as bookmarks or toolbar loca-
tions, or it might be lower level data such as cookies, • The Rendering Engine and Browser Engine subsys-
cache, or security certificates. tems are tightly coupled to each other. As a result,
 User Interface

Persist.
User Interface

User
UI Toolkit (XPFE) User Interface

Data Persistence
User Interface

KWallet
Browser Engine

User, Secure, and

Browser Persist.

Data Persistence
Browser Engine
Browser Engine
Gecko

Persist.
Browser
Rendering Engine KHTML

Rendering Engine

Spider− GTK+
Necko Monkey Expat KIO KJS
Adapter XML Display Backend
Parser
JavaScript XML Networking
Interpreter Parser Qt / X11 Libraries
Security GTK+ / X11 Libraries PCRE
(NSS/PSM)
JavaScript
Networking Display Backend Interpreter

Figure 4. Architecture of Mozilla Figure 5. Architecture of Konqueror

it would be difficult to reuse the Rendering Engine by effort to involve nondevelopers with areas such as documen-
itself. tation, user interface design, issue tracking, and testing.
The mapping of Konqueror’s conceptual architecture
• All graphical elements in the user interface and web
onto the reference architecture is shown in Figure 5. Kon-
pages are specified in Extensible User Interface Lan-
queror makes extensive use of various KDE libraries:
guage (XUL), which abstracts away the details of dif-
KHTML performs parsing, layout, and rendering of web
ferent platform-specific display and widget libraries.
pages; KJS interprets embedded JavaScript code; KWal-
XUL is then mapped onto these each of these libraries
let stores data such as passwords, cookies, and form data
using specially written adapter components. This ar-
with strong encryption and error detection; and KIO is an
chitecture distinguishes Mozilla from other browsers
asynchronous virtual file system which automatically pro-
in which the user platform-specific display and wid-
vides encoding and decoding over common protocols. We
get libraries are used directly, and allows Mozilla to be
note the following observations about the conceptual-to-
ported to different platforms with minimal difficulty.
reference architecture mapping:

4.2 Konqueror • The XML Parser and Display Backend subsystems are
both provided by the Qt[21] toolkit, which serves as
Konqueror[10] is the official web browser of the K Desk- the basis for all KDE applications. That is, these sub-
top Environment (KDE)[9]. It can also serve as a file man- systems are external to the browser itself.
ager and a general-purpose file viewer. The project was • The Perl Compatible Regular Expressions (PCRE) li-
started in January 1999, and its main design goals are speed, brary is used as a backend for the regular expression
standards-compliance, and integration with KDE. We ex- functionality of the JavaScript Interpreter. PCRE is a
amined release 3.3.2, which consists of approximately 613 mature and well tested component used in many other
kLOC, including the required KDE libraries. Konqueror is high-profile open source projects including Python and
written entirely in C++, as is most of the code in KDE. Apache.
We found Konqueror’s codebase to be extremely well or-
ganized. Modules were split up cleanly into subdirectories • Data Persistence is provided at three levels. First,
and there was often a concise design document included some high-level data such as bookmarks and history
with the code explaining the main abstractions and design are stored by Konqueror itself. Second, other high-
decisions. This may be in part due to the extensive docu- level data such as form completions are stored by
mentaion provided by the KDE Quality Team that details KHTML. Third, secure data such as passwords are
various design guidelines and best practices for KDE ap- stored by KWallet, which allows this data to be shared
plication development. This group also makes a conscious with other KDE applications.
 Overall, we found that Konqueror’s developers have
made a concious effort to implement the browser on top User Interface
of existing libraries which take care of difficult tasks. In

Data Persistence
contrast, Mozilla has developed almost all these libraries in- Browser Core
house, delegating only to other libraries only when neces-
sary. A consequence of this is that Konqueror is closely tied
Browser Engine
to UNIX-like operating systems and the Qt toolkit, while
Mozilla supports several different operating systems and
display toolkits. However, as we will see in the next sec- Rendering Engine
tion, Apple was able to adapt Konqueror to their own needs
by removing many of its dependencies.

JavaScript XML
5 Validating the Reference Architecture wwwlib Interpreter Parser Curses

Two additional implementations were chosen against Display Backend

Security
which to validate the reference architecture: Lynx and Sa- (libgnutls)
fari. Lynx was chosen because it is the oldest web browser
Networking
still regularly used and maintained. Safari was chosen be-
cause it represents an interesting mix of open and closed
source technology, and was developed with usability as a Figure 6. Architecture of Lynx
key design goal.
conceptual architecture shows a clear separation between
5.1 Lynx three main subsystems: browser core, networking, and dis-
play backend. We note the following observations about the
Lynx[12] is a text-only web browser for use on cursor- conceptual-to-reference architecture mapping:
addressable, character cell terminals. Its history dates back
to before the age of the World Wide Web and HTML; it • There is no clear separation between the User Inter-
began as an interface for an “organization-wide informa- face, Browsing Engine, Rendering Engine, and Data
tion system.”[6] Hypertext capabilities were then added, Persistence subsystems. This is likely because these
complete with its own link syntax and URI scheme. It subsystems are much simpler in Lynx than in other
next evolved to support the Gopher protocol and distributed browsers due to its text-only nature. For example,
hypertext, functioning also as a database interface. The the rendering engine outputs web pages in linear form
wwwlib library, which provided the first support for WWW rather than attempting to layout elements at appropri-
protocols, was later grafted on making Lynx into a true web ate coordinates, and the user interface relies solely on
browser. We examined release 2.8.5 of Lynx, which con- keyboard input rather than dealing with menus, wid-
sists of approximately 122 kLOC. gets, and mouse events.
Lynx’s age and development process are the primary rea-
sons why its codebase is so large and complex. Although it • Lynx does not contain a JavaScript Interpreter subsys-
was developed by a single student through its early stages, tem or an XML Parser subsystem. This is because
we found that its diverse and constantly changing require- the majority of Lynx’s codebase was written before
ments resulted in a system composed of small fragments of JavaScript existed, and no one has since volunteered
code with no coherent overall structure. In addition, much to add support for it. As a result, Lynx cannot be used
of the code is very low-level and is specific to either the to browse web sites that rely on JavaScript for normal
UNIX or VMS platform, which increases the overall com- interaction. However, many sites only use JavaScript
plexity. To its credit, however, Lynx still remains among the to augment functionality provided by HTML, so Lynx
most popular console browsers on UNIX-based systems. users can still use these sites, albeit with decreased
The mapping of Lynx’s conceptual architecture onto the functionality.
reference architecture is shown in Figure 6. Lynx uses lib-
www, which provides a wide variety of functionality such Overall, the lack of modularity and text-only nature of
as HTML parsing and support for both the HTTP and FTP Lynx make its conceptual architecture much simpler than
protocols. The libgnutls library provides optional support our reference architecture. However, we are still able to
for secure protocols. Lynx also uses the curses library for identify three core subsystems which correspond to some
displaying information on character-cell terminals. Lynx’s of the subsystems in the reference architecture.
 • The Display Backend subsystem is composed of two

Persist.
User Interface

User
complementary libraries: Carbon and Cocoa. Car-
User Interface bon provides a lower-level C API for display routines,

Data Persistence
while Cocoa provides a higher-level Objective C API.

Keychain
Brower Engine (Web Kit)
• Persistent data is handled by three separate system-
Browser Engine wide services that are built into OS X: Preferences,
Keychains, and Caches. The use of these services al-

Persist.
Browser
Adapter (KWQ) lows Safari to to integrate smoothly with other OS X
KHTML applications.
Rendering Engine Overall, Safari’s conceptual architecture corresponds
Core
well with our reference architecture. Safari reuses the core
Foundation KJS Expat Cocoa / Carbon engine from Konqueror, substitues a Mac OS X look and
feel, and makes use of other components and libraries na-
Networking XML Display Backend
PCRE Parser tive to OS X in place of the Linux- and KDE-specific com-
ponents of Konqueror.
JavaScript
Interpreter
5.3 Summary
Figure 7. Architecture of Safari
There are several reasons why a web browser’s architec-
ture would differ from our reference architecture. Some of
5.2 Safari the subsystems in the reference architecture may be imple-
mented as a single subsystem for simplicity, while others
Safari[22] is a web browser developed by Apple Com- may implemented across multiple subsystems for greater
puter for its Mac OS X operating system. The first version flexibility. Furthermore, new subsystems may be added to
was released in January 2003. The main design goals for provide additional capabilities not found in traditional web
Safari are usability, speed, standards-compliance, and in- browsers, while other subsystems may be omitted to make
tegration with OS X. Safari reuses the KHTML rendering the browser more lightweight.
engine and the KJS JavaScript interpreter from the KDE Lynx’s conceptual architecture is much simpler than our
project. Their modified version is called WebCore, and reference architecture. Some subsystems are missing be-
is released under the GNU Lesser General Public License cause they correspond to relatively modern features which
(LGPL). However, the rest of Safari’s code is proprietary, either are not applicable to text-only browsers, or simply
including the browser engine (WebKit) and the user inter- are not supported yet in Lynx. Other subsystems are tighly
face. We examined the source code of release 125 of We- coupled as a result of Lynx’s overall lack of modularity.
bCore and JavaScriptCore, which consists of 114 kLOC of Safari’s conceptual architecture corresponds quite
C++ code and 22 kLOC of Objective C++. Since we could closely to our reference architecture. This makes sense
not extract the proprietary parts, their structure was inferred because Safari is based on the same rendering engine and
from Apple’s developer documentation[1]. JavaScript interpreter as Konqueror; furthermore, it seems
The conceptual-to-reference architecture mapping for as though Apple has used Konqueror as a blueprint for Sa-
Safari is shown in Figure 7 We note the following obser- fari, substituting OS X technologies for the corresponding
vations about Safari’s archtiecture: KDE technologies. Additionally, we observe that Safari
uses the Expat XML parser, which is also found in Mozilla.
• The Rendering Engine is composed of the KHTML Table 1 shows various statistics about the different web
core engine wrapped in the KWQ adapter. KWQ is browsers studied. We note the following observations:
written in Objective C++, which allows it to present an
Objective C API to KHTML, which is written in C++. • Konqueror achieves nearly the same degree of
This was needed for integrating Safari into OS X. standards-compliance as Mozilla with one-quarter of
the amount of code. This may be due to the fact that
• Networking functionality is provided by OS X’s Core Mozilla supports many different platforms, while Kon-
Foundation networking library, used in place of KIO. queror only supports UNIX-like systems running X11
with the Qt toolkit.
• The XML Parser subsystem is provided by the Expat
XML parser, used in place of the XML parser provided • Lynx, while smaller than the other browsers, is
by the Qt toolkit. nonetheless very large for a text-based browser. For
 architecture as part of a study investigating data exchange
Table 1. Approximate web browser statistics between different reverse engineering tools[30]. Mockus,
Project Rel.Lang. Files kLOC Size* Start
Fielding, and Herbsleb have used Mozilla as part of a
Mozilla 1.7.3C++ 10,500 2,400 29 1998
Konq. 3.3.2C++ 3,145 600 17 1996
case study of open source software projects[32]. Fischer,
Lynx 2.8.5C 200 122 2.1 1992 Pinzger, and Gall have analyzed the proximity of fea-
Safari 1.2C++, >750 >136 >2.1 2003 tures in Mozilla based on data in its bug-tracking database,
Obj C Bugzilla[28].
*Represents the compressed tarball size in megabytes.
7 Conclusions
comparisions sake, Links[11], a more recent text-only
browser with a comparable feature set, consists of only We have examined the history and evolution of the web
26 kLOC, approximately one-fifth the size of Lynx. browser domain, developed a reference architecture for web
This may be due to the large amount of legacy code browsers based on two existing implementations, and vali-
in Lynx. dated this reference architecture by mapping it onto two ad-
ditional implementations. Furthermore, we have observed
• We are unable to obtain complete size information for several interesting evolutionary phenomena while studying
Safari because a large portion of the code is closed web browsers; namely, emergent domain boundaries, con-
source. The numbers shown correspond only to the vergent evolution, and tension between open and closed
WebCore engine, and thus represent a lower-bound on source development approaches.
the total size. As the web browser domain has evolved, its concep-
tual boundaries—both external and internal—have become
We are currently investigating how the conceptual archi-
increasingly more defined. However, there are still dis-
tectures of the Mosaic[14], Dillo[5], and Galeon[8] web
crepancies as to the nature of these boundaries. For ex-
browsers correspond to our reference architecture. We
ample, Microsoft has claimed that Internet Explorer is a
would also like to examine web browsers designed specif-
fundamental part of the Windows operating systems, pro-
ically for embedded devices, but at the present time we do
viding rendering functionality to other applications such as
not know of any mature open source implementations.
help browsers and wizards. This extended boundary posed
a problem for third-party browsers such as Netscape who
6 Related Work sought to compete with IE. In a similar example, we have
seen email and usenet client functionality integrated with
There has been some previous research involving ref- the web browser starting with Netscape, and continuing
erence architectures. Eixelsberger has recovered a refer- with the Mozilla Suite. This integration has potentially
ence architecture from a family of embedded, real-time made it more difficult for external clients to compete. Fur-
train control systems, each around 150 kLOC[27]. He ther examples of domain integration include FTP clients and
used a formal Architectural Description Langugage (ADL) local file managers. It will be interesting to observe how the
to describe each system, and then performed commonal- web browser domain adapts to support embedded devices,
ity analysis. Batory, Coglianese, Goodwin, and Shafer such as cell phones and PDAs; these platforms often have
have defined a reference architecture for avionics as part limited amounts of memory, making it undesirable to have
of a project to build a domain-specific software architec- multiple competing applications installed at once.
ture (DSSA) environment for assisting the development of The large amount of effort devoted to creating high-
avionics software.[24]. Hassan and Holt have defined a ref- quality open source browser implementations has had a
erence architecture for web servers, and shown how it maps tremendous influence on the domain. During the “browser
to the conceptual architectures of three systems[31]. wars,” core browser components included proprietary ex-
A product line architecture specifies the architecture for tensions in order to attract customers. Today, increased
a group of products sharing a common, managed set of standardization and pressure to comply with these stan-
features[25, 26]. Product line architectures are similar to dards has led to reuse of core browser components. Rather
reference architectures, although they generally represent a than duplicate effort, browsers often attempt to differenti-
group of systems intended to be produced by a single orga- ate themselves by providing interface enhancements; how-
nization, while reference architectures represent the entire ever, these features seem to be easily duplicated. For ex-
spectrum of systems in a domain. ample, after tabbed browsing was pioneered by NetCap-
Finally, there have been some previous case studies ex- tor, it quickly began appearing in other browsers such as
amining various aspects of Mozilla’s architecture and devel- Opera and Mozilla. Similarly, popup blocking and auto-
opment process. Godfrey and Lee have extracted Mozilla’s matic web form filling are now commonplace, suggesting
that web browser domain is exhibiting a form of convergent [11] Links web browser home page. http://links.
evolution[29]. sourceforge.net.
The availability of mature browser components has also [12] Lynx web browser home page. http://lynx.isc.org.
resulted in tension betwen open and closed source devel- [13] Maxthon web browser home page. http://www.
maxthon.com.
opment approaches. The Mozilla project was founded with
[14] Mosaic web browser home page. http:
the intention of creating a mature, open source browser plat- //archive.ncsa.uiuc.edu/SDG/Software/
from that could be used as the basis for other browsers, both Mosaic/NCSAMosaicHome.html.
open and closed. Indeed, the last two releases of Netscape [15] Mozilla application suite transition plan. http://www.
have been based on Mozilla and have been closed source. A mozilla.org/seamonkey-transition.html.
similar situation has occurred with Apple’s Safari, which is [16] Mozilla project home page. http://www.mozilla.
a closed source browser based on Konqueror’s open source org.
engine. Although not required by the licence, Apple has [17] Netcaptor web browser home page. http://www.
voluntarily contributed their changes to open source code netcaptor.com.
[18] Omniweb web browser home page. http://www.
back to the community. Conversely, Internet Explorer rep-
omnigroup.com/applications/omniweb.
resents a closed source browser component that can po- [19] Opera web browser home page. http://www.opera.
tentially be embedded in an otherwise open source prod- com.
uct. Interstingly enough, the upcoming version of Netscape [20] QLDX reverse engineering toolkit home page. http://
promises to embed both the Mozilla and IE engines, allow- swag.uwaterloo.ca/qldx.
ing users to switch on the fly. [21] Qt application development framework home page. http:
While we have seen applications composed of both open //www.trolltech.com/products/qt.
and closed source components before, the interaction usu- [22] Safari web browser home page. www.apple.com/
safari.
ally takes place on the perimeter, as is the case with closed
[23] Webcore framework home page. http://developer.
source binary modules for the Linux kernel. We believe the apple.com/darwin/projects/webcore.
heterogeneous combination of core open and closed source [24] D. Batory, L. Coglianese, M. Goodwin, and S. Shafer. Cre-
software components within individual systems makes the ating reference architectures: an example from avionics. In
web browser domain unique and interesting. Proceedings of the 1995 Symposium on Software Reusability
(SSR ’95), pages 27–37, 1995.
[25] J. Bosch. Design and use of software architectures:
Acknowledgements adopting and evolving a product-line approach. ACM
Press/Addison-Wesley Publishing Co., New York, NY,
We thank Ali Echihabi for his contributions to an earlier USA, 2000.
project out which this paper has grown, as well as Ric Holt [26] P. Clements and L. M. Northrop. Software product lines:
for his feedback and advice. practices and patterns. Addison-Wesley Longman Publish-
ing Co., Inc., Boston, MA, USA, 2001.
[27] W. Eixelsberger, M. Ogris, H. Gall, and B. Bellay. Software
References architecture recovery of a program family. In Proceedings of
the 20th International Conference on Software Engineering
[1] Apple developer documentation. http://developer. (ICSE ’98), pages 508–511, 1998.
apple.com/documentation. [28] M. Fischer, M. Pinzger, and H. Gall. Analyzing and relating
[2] Avant web browser home page. http://www. bug report data for feature tracking. In Proceedings of the
avantbrowser.com. 10th Working Conference on Reverse Engineering (WCRE
[3] Camino web browser home page. http: ’03), pages 90–99, 2003.
//caminobrowser.org. [29] D. J. Futuyma. Evolutionary Biology. Sinauer Associates,
[4] Cascading Style Sheets home page. http://www.w3. Sunderland, MA, USA, 3rd edition, 1998.
org/Style/CSS. [30] M. Godfrey and E. H. S. Lee. Secrets from the monster:
[5] Dillo web browser home page. http://dillo.org. Extracting mozilla’s software architecture. In Second Inter-
[6] An early history of Lynx. http://www.cc.ku.edu/ national Symposium on Constructing Software Engineering
˜grobe/early-lynx.html. Tools (CoSET ’00), June 2000.
[7] ECMAScript language specification. http://www. [31] A. E. Hassan and R. C. Holt. A reference architecture for
ecma-international.org/publications/ web servers. In Proceedings of 7th the Working Conference
standards/Ecma-262.htm. on Reverse Engineering (WCRE ’00), pages 150–160, 2000.
[8] Galeon web browser home page. http://galeon. [32] A. Mockus, R. T. Fielding, and J. Herbsleb. A case study
sourceforge.net. of open source software development: the apache server. In
[9] K Desktop Environment home page. http://kde.org. Proceedings of the 22nd International Conference on Soft-
[10] Konqueror web browser home page. http: ware Engineering (ICSE ’00), pages 263–272, 2000.
//konqueror.org.