Concrete Architecture of Mozilla Firefox (version ) Iris Lai Jared Haines John,Chun-Hung,Chiu Josh Fairhead July 06, 2007

Outline Modified Conceptual Architecture Firefox Conceptual Architecture vs. Concrete Architecture Necko Concrete Architecture Interface architecture in Necko Handling downloads in Necko Necko Conceptual Architecture vs. Concrete Architecture Design Patterns and Architecture Styles

Modified Conceptual Architecture of Mozilla Firefox

Modified Conceptual Architecture Display backend module not part of Gecko, tightly couple with local machine, provides widget toolkit API that can be use by UI module Remove XPCOM from conceptual architecture since every modules relates to XPCOM. Conceptual should focus on main components and conceptual relations. The dependency between Necko and XML Parser was also eliminated according to our concrete architecture.

Firefox Concrete Architecture

We divide source into nine parts(modules)  Runtime  Utility -functions (nsUnicharUtils)  User Interface  Gecko  Data Persistence  Java Script  Display Backend  XML Parser  Necko

Conceptual vs Concrete Architecture The concrete architecture shows more relations and dependencies than the conceptual architecture. There are two more components in the concrete architecture: Runtime and Utility.

Necko Concrete Architecture

Network Service Protocol Handler Socket Transport Stream Converter Security URL Handler Necko Utility

Necko Concrete Architecture Network Service  Network Service contains essential modules nsIOService provides major Necko services. It manages protocol handlers and provides interface for creating URI objects from URI strings. nsSocketTransportService manages socket transport service which builds physical connections protocol handlers and the Internet.

Necko Concrete Architecture Protocol Handler  In Protocol Handler layer, the corresponding protocol is selected according to the URI schema.  Protocol Handler can handle requests that use ftp, http, or gopher protocol. Socket Transport  Socket Transport is a layer between Protocol Handler and the Internet.

Necko Concrete Architecture Stream Converter  Stream Converter provides stream conversion services to Protocol Handler. Security  Uses Mozilla PSM URL Handler  URL handler is called from Gecko (docshell) when a URI is requested

Necko Concrete Architecture Necko Utility  DNS  Cookie  MIME  Cache

Interface architecture in Necko

nsIURL and nsINetService are implemented in Network Service subsystem. nsIProtocolHandlers are implemented in Protocol Handler subsystem. nsIprotocolConnection is implemented by channels. Socket transports and file transports are implemented in Network Service subsystem and Socket Transport subsystem. Necko also handles transport threads.  There is a single socket transport thread that manages a pool of file descriptors for all outstanding socket requests.  This is similar to the Master-Slave design pattern. A master is monitoring all its slaves and talks to clients. In Necko, the masters are located in Network Service package, and slaves are implemented in other subsystems such as Protocol Handler.

Handling downloads in Necko

Necko Conceptual Architecture vs. Concrete Architecture There is no Protocol Connection subsystem in the Necko concrete architecture.  The Protocol Connection is implemented by channels. There are two types of channels: synchronous and asynchronous. There are extra subsystems in Necko concrete architecture  Stream converter  Necko Utility. Necko Utility includes DNS, Cookie, MIME, and Cache.

Design Patterns Observer  RequestObserver  Cache module Abstract Factory  SocketProviderService, StreamConverterService Singleton  IOService, CookieService Facade  SecretKeyFacade

Architecture Styles Pipe and Filter URL Network Service Protocol Handler Protocol Connection Transport Implicit Invocation

References [1] Mozilla: Core Modules & Libraries [2] Network library documentation [3] [4] [5] Multithreading in Necko - ml ml [6] [7] MDC Glossary -