L'Architecture de Mozilla

Une architecure impos‰e par l'importance du projet

L'importance du projet mozilla impose pour la r‰alisation du produit un effort consid‰rable de la part des ‰quipes de travail pour fournir une architecture logicielle robuste. Cette robustesse implique, entre autres, un environement cross-platform, une forte souplesse dans la r‰alisation et l'extension des fonctionnalit‰s du produit ainsi qu'un d‰ploiement le simple possible. L'ensemble de ces objectifs devant ‰galement Štre r‰alis‰s en essayant de se rapprocher des standarts existants et des derniˆres technicit‰s (environnements multi-threads, architectures distribu‰es ...).

C'est dans cet esprit qu'un regroupement des diff‰rents domaines fonctionnels de mozilla a ‰t‰ r‰alis‰.

Les domaines fonctionnels :

Editor
Framesets and History
Image Library
Intel MMX Enhancements
Internationalization
JavaScript Library
Layout and Layers
MWContext Function Dispatch
NetHelp Status
Network Library
NSPR
WinFE

Pour plus de d‰tail sur ces domaines, consulter : http://www.mozilla.org/docs/tplist/tplist.html

Pour permettre la r‰alisation des parties de Mozilla d‰crites ci-dessus, des projets de d‰veloppement ont ‰t‰ mis en en place. Dans ces projets, certains concernent (sont concern‰s) trˆs particuliˆrement (par) la mise en place des couches logicielles n‰c‰ssaires € l'architecture de Mozilla (en rouge).

Les projets de d‰veloppement :

SilentDownload
XPCOM
XPToolkit
New Layout
JavaScript
JavaScript Debugging
Mail/News
Calendar
Open JVM Integration
ElectricalFire
Configurable UI
ColorSync
Internationalization (I18N)
Localization (L10N)
Performance
Directory (LDAP)
Autoconf
Grendel
Unix
Ports
Editor
CCK

Cryptozilla
mozillaZine

Pour plus de d‰tail sur ces domaines, consulter : http://www.mozilla.org/projects.html

L'importance du nombre de projets implique directement une architecture modulaire pour le d‰veloppement et la mise en commun des diff‰rents d‰veloppements. Chaque projet donne donc lieu au d‰veloppement d'un certain nombre de modules (Ensemble de fichiers impl‰mentant une partie du projet global Mozilla). Nous pr‰sentons, ci-dessous, l'ensemble des modules en cours de d‰veloppement ou d‰velopp‰s.

Les modules:

Module: 2-D Graphics
Module: Aurora/RDF BE
Module: Base XPCOM Classes
Module: Berkeley DB
Module: Browser Hooks
Module: Build Config
Module: CCK (Client Customization Kit Source Code)
Module: Clipping and Compositing
Module: ColorSync Branch
Module: Composer (Editor/Composer)
Module: Dialup
Module: Directory SDK
Module: Document Object Model
Module: ef (Electrical Fire)
Module: Embeddable Web Browser
Module: GTK (supported X widgetry and gfx)
Module: HTML to Text/PostScript Translation (b)
Module: I18N Library
Module: Image Conversion Library
Module: ImageLib
Module: Java and JS Capability-Based Security
Module: Java Stubs (OJI)
Module: JavaScript
Module: JavaScript Debugger
Module: jpeg (JPEG Image Handling)
Module: JPEG Image Handling
Module: LiveConnect
Module: Macintosh FE
Module: MIMELib
Module: Mozilla Tools
Module: mozilla-toplevel
Module: NetLib
Module: New HTML Layout Engine
Module: New HTML Parser
Module: New HTML Style System
Module: New Layout Engine
Module: NSPR (Netscape Portable Runtime)
Module: PerlConnect
Module: PICS
Module: Plugins
Module: PNG Image Handling
Module: Preferences (Preference and profile management libraries)
Module: Progress Window
Module: Registry
Module: Security Stubs
Module: Silent Download
Module: SmartUpdate
Module: Windows FE
Module: XML
Module: XP File Handling
Module: XP Miscellany
Module: XP Widgets
Module: XPApps
Module: XPCOM
Module: XPToolkit
Module: Zlib

Pour plus de d‰tail sur ces domaines, consulter : http://www.mozilla.org/owners.html

Le grand nombre de modules et le nombre de developpeurs qui y sont associ‰s (ainsi que l'aspect developpement ouvert € tous) impose une ‰tude sp‰cifique de leur interfa‡age. Ce sont, € la fois, le systˆme et l'interfa‡age de modules, les ‰l‰ments mis en place pour tirer le plus grand partie de cette structure et les contraintes li‰es € la notion de cross-plateform qui seront pr‰sent‰s dans la suite de ce document.

Afin de garantir l'aspect cross-platform, les d‰veloppeurs respectent un grand nombre de contraintes sur l'utilisation du langage C++.
Ces contraintes de d‰veloppement pourront Štre consult‰es € l'adresse suivante : http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html

Pr‰sentation des couches logicielles

Le graphique ci-dessous pr‰sente la structure sous-jacente € tous modules

NSPR : API offrant des services de bas niveau (thread, entree sortie, ...) ind‰pendants de l'OS sous-jacent.

XPCOM : Fournit tous les services n‰c‰ssaire € la gestion d'un module. Bas‰ sur le modˆle COM de Microsoft.

XPIDL : Langage / Module de description d'interfaces pour automatiser la g‰n‰ration de glue n‰c‰ssaire € la communication entre module XPCOM. Bas‰ sur les IDLs CORBA (Systˆmes distribu‰s).

XPConnect : Couche logiciel qui permet via la description d'IDLs la communication entre des composants XPCOM et des composants javascript.

Le runtime cross-plateform : NSPR

NPSR est une couche logicielle qui fournit des services du systeme d'exploitation tels que la gestion des threads, des fichiers, des entr‰es/sorties sur le r‰seaux, la gestion de la m‰moire (allocation, lib‰ration ...), etc ... Les services offerts sont ind‰pendants du systˆme d'esploitation sous-jacent. Une des application direct de cette couche est de fournir les ‰l‰ments n‰c‰ssaires € la r‰alisation de la machine virtuelle JAVA. L'objectif de NSPR est donc de fournir un ensemble complet et uniforme d'op‰rations de la couche systˆme quelque soit l'environement d'origine (NT, UNIX ...) en exploitant les meilleurs fonctionnalit‰s de chaque systˆme.

Les threads

La partie principale de NSPR est la gestion des threads en offrant une API commune aux impl‰mentation industrielles. Elle utilise autant que possible les fonctionalit‰ offertes par le systˆme.

On retrouve notament dans l'API :

La creation des threads
Le scheduling des thtreads
La synchronisation entre thread (section critique, ...).

Les threads NPSR sont des threads l‰gers et leur scheduling se r‰partit entre 2 domaines : local et global.
Les threads du domaine local correespondent € des threadsattach‰s € un seul processus et leur ordonnancement se fait € l'int‰rieur du process (G‰r‰ pa NPSR).
Les threads du domaine global sont des thread directement ordonnanc‰s par le le systˆme d'exploitation et non par NSPR.

Les Entr‰es/Sorties r‰seau

Elle sont bas‰s sur le modˆle des sockets BSD.

La gestion des adresses r‰seau

Fournit un ensemble d'op‰rations permettant de manipuler les adresses r‰seaux.

La gestion du temps

Pr‰sente deux services : la gestion des intervalles de temps et les fonctions du calendrier.

La gestion m‰moire

Fournit toutes les fonctions de getion m‰moire du type de malloc, realloc, free ...

Les op‰ration de linkage

Chargement de dll ...

NSPR est fournit pour les pateformes : WIN32, MACINTOSH, UNIX.

pour plus de d‰tails : http://www.mozilla.org/docs/refList/refNSPR/contents.html

Une architecture modulaire inspir‰e de COM : XPCOM

Comme nous l'avons d‰j€ pr‰cis‰, l'architecture logiciel de mozilla est fortement modulaire. Le projet XPCOM a pour but de fournir un ensemble de classe permettant de rendre possible la r‰alisation d'un composant de mozilla de maniˆre ind‰pendante de l'ensemble et de l'ajouter € cet ensemble facilement. Pour cela un solide systˆme d'interfa‡age est n‰c‰ssaire de maniˆre € permettre l'accˆs de maniˆre uniforme de l'API d'un module € un autre. Pour r‰aliser cela, le groupe de travail de XPCOM s'est inspir‰ des principes du modˆle COM de Microsoft pour developper son propre systˆme de modularisation.

Module

Un module est un ensemble de fichier qui forme un paquet coh‰rent, en g‰n‰ral, une librairie (DLL) ou un ‰x‰cutable. L'ensemble des modules dans Mozilla devrait-Štre construit € partir d'XPCOM.
Dans la suite du document nous considerons qu'un module est une partie du logiciel utilisant la technologie XPCOM.

Interfaces

Comme nous l'avons dit, le principe de XPCOM est bas‰ sur le modˆle COM de Microsoft. L'objectif de XPCOM est de fournir un moyen uniforme de fournir l'accˆs aux fonctionnalit‰s d'un module. Ceci est r‰alis‰ au travers d'un systˆme d'interface. Une interface est une classe qui propose un ensemble de fonctionnalit‰ (m‰thodes) impl‰ment‰s dans le module. Elle ne pr‰-suppose rien de l'impl‰mentation des fonctionnalit‰s qu'elle propose.

Dans le cas d'XPCOM les Interface sont des interfaces C++ virtuelles pure :

virtual int foo(int bar) = 0;

Les interfaces virtuelles pures fournissent un m‰canisme ais‰ pour passer des ensembles de fonctions entre modules contenues dans des librairies s‰par‰es et potentiellement charg‰es dynamiquement. Chaque interface est associ‰e € un num‰ro d'identification appel‰ IID.

A la base du systˆme d'interface se trouve la classe nsISupports (L'‰quivalent de la classe IUnknown de COM) qui fournit les m‰canismes d'interogation d'interface via la m‰thode QueryInteface() et la gestion des r‰ferences sur l'objet cr‰‰.

Les objets Factory

Les Factories (nsIFactory) sont des classes particuliˆres dont le rŸle est de cr‰er des instances d'autres classes. (Equivalence chez COM avec la classe IClassFactory). Ceci permet de cr‰er des objets sans avoir accˆs € la d‰claration de cet objet au moment de la compilation. L'impl‰mentation et la d‰claration de la classe se trouve donc cach‰ € l'utilisateur. On r‰duit ainsi les d‰pendances € la compilation et au linkage.

L'interface repository

L'objectif principale de la modularisation et de reduire au maximum les d‰pendances de linkage. Pour cela une correspondance entre les Identifiants des Interfaces et les interfaces est stock‰ dans une classe la "NSRepository". Elle fournit les m‰thodes pour la gestion du stockage interfaces (M‰canismes de registration)

pour plus de d‰tails :
http://mozilla.org/docs/tplist/catFlow/modunote.htm
http://www.microsoft.com/oledev/olecom/title.htm

La g‰n‰ration automatique des interfaces : XPIDL

Une recherche a ‰t‰ effectu‰e afin de changer l'ancienne version du Plugin API afin de faciliter l'extention de Mozilla.
Les d‰savantage de l'ancienne API ‰tait :

Les points d'entr‰e de l'ancien browser ne permettait pas facilement l'ajout de nombreuse fonctions et leur maintenance (Versioning).
Des fichiers de "glue" fait € la main ‰taient n‰ssaires entre les diff‰rentes DLLs.
Problˆmes pour intervenir sur des d‰veloppement pr‰visionel ie compatibilit‰ ascendante (Pas de notion d'interface).

L'utilisation des interfaces XPCOM permet de resoudre ces problˆmes.

Cependant l'‰criture des glues pour permettre l'utilisaton des interfaces propos‰s par les modules d‰velopp‰s € l'aide d'XPCOM peuvent Štre simplifi‰es en proposant un standart de d‰claration des interfaces et en g‰n‰rant le parties n‰c‰ssaire € leur utilisation.
C'est l'objectif d'XPIDL.

XPIDL est le langage de description d'interface utilis‰ par l'outil xpidl pour g‰n‰rer les interfaces, la documentation et la "glue" pour les interfaces XPCOM. Il est directement inspir‰ des IDL existant pour les OMG (CORBA) avec quelques extension pour utiliser les IIDs et autres ‰l‰ments sp‰cifiques d'XPCOM. L'outil xpidl g‰nˆre € partir de la description en XPIDL les interfaces XPCOM (nsIFoo.h € partir de nsIFoo.idl), de la documentation € la javadoc et de la glue pour l'interaction avec Javascript.
Cette glue est essentielle € l'utilisation de composants JavaScript via XPConnect.

Connexion de composants javascript via XPIDL et XPConnect

XPConnect est une technologie qui vise € permettre € du code Javascript d'appeler des objets C++ et vice-versa par l'interm‰diaire des interfaces XPCOM.

L'XPIDL g‰nˆre les fichiers en-tŠte pour l'inclusion dans du code C++ ainsi que des fichier d'info sur les librairies XPCOM. Ces fichier d'information sont ind‰pendants de la plateforme et pouvant-Štre facilement acc‰d‰s € l'ex‰cution. Ces fichiers consistent en une d‰scription pr‰cise des interfaces auxquelles ils sont li‰s (Description des m‰thodes, paramŠtres ...). A partir de ces fichiers une glue XPConnect va pouvoir Štre g‰n‰rer afin de r‰aliser le processus de Marshallisation des m‰thode et paramŠtres et permettre ainsi le d‰clenchement d'op‰ration des objets XPCOM par du code JavaScript et Vice-Versa.