Recommend Me


Vendredi 17 février 2006

Histoire et architecture de Mozilla

(Linux Magazine France n°56 - Décembre 2003)

Depuis la libération du code source de Netscape, Mozilla est devenu un navigateur far du monde open-source. Dans cette série d’article nous allons voir que derrière une réputation d’usine a gaz, Mozilla cache une formidable architecture qui permet facilement, à qui a un minimum de notions de développement d’adapter, de modifier voir d’améliorer ce formidable outil. Mais vous vous rendrez compte que nous pouvons aller beaucoup plus loin en créant de véritables applications grâce à Mozilla.

Un peu d’histoire

L’histoire de Mozilla s’apparente plus à une véritable épopée qu’une simple suite d’évènements qui mènent à l’aboutissement d’un projet libre.

Pour la plus part, Mozilla est le résultat du passage en open-source du code de Netscape. C’est vrai dans un certain sens, mais en réalité dans son acception véritable, la dénomination “Mozilla” était le nom de code de développement du produit devenu Netscape Navigator et plus tard Netscape Communicator. Le nom “Mozilla” (inspiré par Jamie Zawinski) viens de l’association entre l’idée que Netscape Navigator devait être un tueur de Mozaic[1] (”Mozaic Killer”) et un jeu de mot avec le plus gros prédateur que la science fiction est porté : Gozilla (et il y en a qui vont dire que les informaticiens n’ont pas d’humour ;)).

En 1998, le 31 mars exactement, le code source de Netscape est ouvert à la communauté sous une licence open source. La société Netscape créé en même temps une association à but non lucratif chargé de superviser le développement du navigateur tout en s’assurant de nouvelles compétences. Cette association prendra le nom de mozilla.org ! A partir de ce moment là, Mozilla n’est plus un nom de code, mais représente tout ce qui est afférent au logiciel open source créé par Netscape.

A cette époque, pour ceux qui s’en souviennent, la mascotte de Netscape était un petit lézard vert. Mais bon… donner son code est une chose, donner son lézard en est une autre. Et Jamie Zawinski (toujours lui) va alors faire adopter le Tyrannosaure rouge comme nouvel emblème pour le projet grâce au travail de Shepard Fairey qui créa le dessin modèle de mozilla.org. Ceci sera un des éléments qui vont contribuer à donner de la distance entre le projet Mozilla et les produits de Netscape.

En fait, ce qui va réellement entériner la fracture est la décision, par mozilla.org, en octobre 1998, de laisser tomber les sources qui ont permis sa création pour repartir sur de nouvelles bases[2]. Avant cette (grave) décision, l’idée était de créer un moteur de rendu plus rapide multi plate-formes, respectueux des standards et qui devait aider à la sortie de Netscape 6. Mais l’ambition débordante pousse les acteurs du projet dans une autre voie. L’idée n’est plus de créer un simple navigateur, mais un véritable outil multi plate-formes, sur lequel un nouveau logiciel pouvait-être développé puis tourner sur n’importe quel ordinateur supporté par cette nouvelle base, y compris un navigateur (ouf !). C’est ceci qui va donner naissance à ce que l’on connaît aujourd’hui sous le nom de “Gecko”. Grâce à cela, la plus grosse partie du code (~95%) est multi plate-forme, et on peut dire (sans trop se tromper) qu’il ne doit pas rester plus de 10% de code provenant de Communicator 4.

Bien que la scission soit visible entre Mozilla et les produits Netscape, l’équipe travaillant sur le nouveau projet est financée par Netscape qui peut alors profiter du nouveau moteur pour sortir son navigateur en version 6 (puis 7). En octobre 1998 Netscape est racheté par AOL et pourtant il faudra attendre 2002 (et la sortie de Mozilla 1.0) pour que ce dernier adopte “Gecko” dans son logiciel (version 7) !!! Mais le succès est de courte durée car exactement un an plus tard (en octobre 2003) AOL se sépare définitivement des derniers rescapés de Netscape travaillant sur Mozilla en leur laissant tout de même une petite enveloppe de 1 million de dollars pour continuer leur travail. Mais avant cela, durant l’été 2003, mozilla.org s’est transformé en “Fondation Mozilla”, ayant pour but de continuer la gestion des sources de Mozilla.

Après la sortie de Mozilla 1.0, un nouveau plan de développement est mis en place[3] et doit mener à la version actuelle : la 1.4. Cette version, sortie en juin 2003, remplace définitivement la version 1.0 en qualité de branche stable. Avec la création de la Fondation Mozilla, les plans changent et de nouvelles orientations sont prises[4] avec une intention avérée de refondre en profondeur certains composants pour aboutir à la version 1.6.

Afin de re situer l’ensemble de ces évènement dans la fabuleuse histoire des navigateurs, voici un petit tableau récapitulatif (source [5]):

Date Navigateur
1990 Tim Berners-Lee lance le 1er navigateur Web appelé World Wide Web qui tourne sur NeXT
mars 1993 Lancement de Lynx
1993 Mosaic (navigateur mode texte) tourne sur X-Windows, Unix et Mac
décembre 1994 Netscape crée Mozilla qui servira de base au navigateur Netscape 1.0
août 1995 Internet Explorer est inclus dans Windows 95
septembre 1995 Netscape Navigator 2.0
1996 Internet Explorer 2.0
1996 Première version d’Opera
août 1996 Netscape Navigator 3.0
août 1996 Internet Explorer 3.0
juin 1997 Netscape Navigator 4.0
mars 1999 Netscape Navigator 4.5
mars 1999 Internet Explorer 5
septembre 1999 Netscape Navigator 4.7
novembre 2000 Netscape Navigator 6
juin 2002 Mozilla 1.0
septembre 2002 Netscape 7.0
juin 2003 Mozilla 1.4 et Netscape 7.1

L’avenir

Comme à chaque changement, la constitution de la Fondation Mozilla à été l’occasion de mettre en place un nouveau plan de développement[4]. La nouvelle roadmap fixe les objectifs à suivre pour aboutir à la future 1.6. Voyons, sans trop entrer dans le détail, ce que l’on nous prépare.

En résumé, ceux qui lisent les news sur DLFP (ou autre) le savent déjà, le futur de Mozilla repose sur Firebird pour la partie navigateur et Thunderbird pour le client mail. En fait, Thunderbird est lui-même déjà basé sur le nouveau toolkit XUL utilisé par Firebird. Dans le détail, cela ne devrait pas perturber les utilisateurs (au contraire), mais apporter pas mal de changement du coté développeurs. Là où Mozilla 1.4 apportait une modularité déjà très intéressante, Firebird pousse le concept encore plus loin. Grâce à cette nouvelle architecture chaque composant devient indépendant des autres et est donc plus facile à maintenir et à faire évoluer. De plus chaque élément peut être utilisé indépendamment des autres ce qui les rend moins lourd donc moins consommateur en ressource et donc plus agréables à utiliser.

Les versions 1.5 et 1.6 reposeront donc sur un nouveau toolkit XUL. Ce nouveau toolkit n’est pas qu’une reprise en terme de fonctionnalités de l’existant. Dans le fond il s’agit d’une reimplémentation complète, 100% compatible avec l’existant, mais apportant sont lot de nouvelles fonctionnalités. Comme cela est bien précisé dans le plan de développement, ce n’est ni un abandon, ni un changement du toolkit, c’est une simple mise à jour pour utiliser “le toolkit XUL de dernière génération”.

Dans le même sens, un travail sur Gecko est en cour. Il s’agit ici aussi d’avoir un coeur plus performant, moins complexe et donc plus facile à maintenir.

Attention, ne nous méprenons pas, il ne s’agit pas d’abandonner certaines partie au profit d’autres, mais de mettre en place une organisation plus structurée aussi bien du point de vue de l’architecture logiciel que de la gestion des personnes travaillant sur le projet. Que les utilisateurs se rassurent, ils retrouveront (s’ils le souhaitent - et c’est la le changement majeur) tout ce qu’ils ont déjà.

Avec cette nouvelle architecture, il sera aussi beaucoup plus facile d’imaginer des développement basés sur le toolkit Mozilla/Firebird pouvant fonctionner sans être obligé d’installer toute la suite logiciel qui va avec.

Autour de Mozilla

Comme nous l’avons vu, l’objectif fixé lors du démarrage du chantier devant conduire à la création de Mozilla 1.0 était d’avoir une moteur permettant le développement d’autre logiciels avec un niveau de portabilité accru. Et c’est grâce à cela que nous trouvons aujourd’hui sur le terrain une multitudes de projets basés sur Mozilla.

La plus part de ces projets sont des navigateurs internet. Parmi ceux ci on retiendra évidement Firebird qui, en plus d’être basé sur Gecko, utilise XUL, mais nous pouvons aussi citer Galeon, Camino, K-Meleon, ishzilla, Salamander Web Browser, Beonex, Nautilus et bien entendu Netscape. J’en oublie certainement, désolé pour eux !

En plus des navigateurs, on trouve des projets tels que :

  • TopStyle, outils d’aide à la création de feuilles de style (CSS) pour Windows,
  • AOL et sa suite internet,
  • Komodo, produit par ActiveState,

Les nouvelles orientations prises vont certainement permettre de voir fleurir un nombre croissant de projets n’ayant plus rien à voir avec la simple navigation sur internet et surtout beaucoup moins lourdes.

Il faut aussi noter que la volonté affiché des le départ de faire de Mozilla un logiciel ultra portable à porté ses fruits puisqu’il tourne aujourd’hui sur la majorité des systèmes : Linux bien entendu mais aussi tous les Un*x (dont IRIX, True65, AIX), Windows et Mac ou encore OpenVMS et 0S/2.

L’architecture de Mozilla

Depuis la version 1.0 et jusqu’à la 1.4, l’architecture de Mozilla est relativement simple. Elle est composée de trois couches superposées : en bas Gecko, au milieu le toolkit XPFE et au-dessus l’ensemble de la suite logiciel composée du navigateur, du client mail et toutes les applications annexes (calendrier, DOM inspector, console Javascript…). La nouvelle organisation ressemble fortement à l’ancienne, la différence venant de la modularisation des composants placés ” au sommet “. En effet entre les versions 1.0 et 1.4 on ne pouvait pas représenter les composants de la suite autrement qu’en faisant un ” gros cadre ” englobant l’ensemble.

Dans la nouvelle architecture, chacun de ces composants étant autonome, ils viennent se greffer sur le toolkit tout en conservant des possibilités d’interaction entre eux. Nous voyons même apparaître des ” modules de modules ” (les puristes m’excuseront de ce raccourci). C’est par exemple le cas du client mail qui peut être utilisé indépendamment du navigateur, mais peut tout aussi bien apparaître comme une extension de ce dernier.

Installer Mozilla

Bon, finis le cour d’histoire, passons aux choses sérieuses. Dans la suite nous travaillerons avec la version disponible sur la CVS. Ne vous étonnez donc pas si vous constatez des différences entre ce qui va être vu tout au long de cet article (et des suivants) et ce que vous pourrez expérimenter de votre cote. Ce que je vais vous présenter par la suite, en terme de modification d’interface ou de développement en général, devrait fonctionner chez vous, y compris si vous travaillez avec une version 1.4.

Avant de se lancer à corps perdu dans la compilation, il faut vérifier la présence sur votre système d’un certain nombre de packages. Je laisse à votre initiative l’installation de ces derniers en vous en donnant simplement la liste :

  • g++ et les librairies de développement qui vont avec
  • Perl
  • make
  • cvs
  • GTK+ et GLib
  • libIDL
  • zip

Une fois ces packages installés, nous pouvons récupérer les sources. Pour cela il faut commencer par positionner la variable d’environnement CVSROOT :

helium:~# export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

La récupération des sources proprement dit se fait en plusieurs étapes. En premier on récupère le fichier mozilla/client.mk puis, grâce à ce fichier on récupère le reste. Cette dernière étape peut prendre beaucoup de temps en fonction de votre connexion internet. Le mot de passe du serveur CVS est anonymous.

helium:~# cvs login helium:~# cvs co mozilla/client.mk ... helium:~# cd mozilla helium:~# make -f client.mk checkout ... helium:~#

Je vous déconseille fortement de faire directement un cvs co mozilla au risque de récupérer beaucoup de choses inutiles voir périmées ;)

A partir de maintenant tout se passe comme une compilation classique grâce au jeu de commandes habituelles. Comme pour tout bon logiciel qui se respecte, vous avez tout loisir de passer un certain nombre d’options lors du lancement de la configuration. Pour cela vous avez deux possibilités :

  • faire un ./configure –help et rechercher les options qui vous sont utiles,
  • utiliser le “générateur de configuration” mis à votre disposition sur le site de Mozilla à l’adresse http://webtools.mozilla.org/build/config.cgi. Il s’agit, comme vous pouvez le voir, d’un script CGI qu permet de sauvegarder dans un fichier les options que doit utiliser le script de configuration.

Pour ma part je préfère cette dernière solution. Aller à l’adresse web donnée et cochez les options qui vous intéressent. Quand vous avez terminé, cliquez sur le bouton “Preview Build Scrip”. Sur la page suivante, comme c’est indiquez, cliquez sur “Save the script”. Vous aurez alors un fichier ~/.mozconfig qui vous évitera de taper une commande à rallonge au risque de vous tromper. Voici ce que cela donne chez moi :

#~/.mozconfig : # sh # Build configuration script # # See http://www.mozilla.org/build/unix.html for build instructions. #   # Options for client.mk. mk_add_options MOZ_MAKE_FLAGS=-j4   # Options for 'configure' (same as command-line options). ac_add_options --with-pthreads ac_add_options --enable-calendar

C’est bon, vous pouvez lancer le script de configuration :

helium:~/mozilla# ./configure Adding configure options from /root/.mozconfig:   --with-pthreads   --enable-calendar loading cache ./config.cache checking host system type... i586-pc-linux-gnu checking target system type... i586-pc-linux-gnu checking build system type... i586-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc  ) works... yes checking whether the C compiler (gcc  ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes ... creating Makefile creating config/Makefile creating config/autoconf.mk creating ldap/Makefile creating ldap/build/Makefile creating ldap/clients/tools/Makefile creating ldap/include/Makefile creating ldap/libraries/Makefile creating ldap/libraries/libldap/Makefile creating ldap/libraries/libprldap/Makefile creating ldap/libraries/libldif/Makefile creating ldap/libraries/liblber/Makefile creating ldap/libraries/libiutil/Makefile creating ldap/libraries/libssldap/Makefile helium:~/mozilla#

Et c’est enfin le grand moment de lancer le make. Maintenant vous pouvez aller prendre un bon café !!!

Pour ceux qui n’aiment pas perdre du temps, il y a un moyen pour en gagner. Pour cela, après avoir récupérer le fichier mozilla/client.mk, créez le fichier ~/.mozconfig et au lieu de finir la récupération des sources, de lancer le script de configuration à la main et le make, faite directement un

helium:~/mozilla# make -f client.mk

Ceci enchaînera pour vous l’ensemble des étapes.

Une fois que la compilation est terminée, vous pouvez utiliser votre “Mozilla nouveau” :

helium:~/mozilla# cd dist/bin helium:~/mozilla# ./mozilla

La suite, la suite…

Dans les articles suivant je vais vous montrer comment utiliser le toolkit de Mozilla pour développer des extensions. Nous allons successivement voir comment étendre l’interface avec XUL avant de nous lancer dans la création de composants grâce à XPCOM. Dans un dernier article nous utiliserons des langages de script pour créer des composants, mais aussi et surtout pour les utiliser en dehors de Mozilla.


[1] http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html
[2] http://www.mozilla.org/roadmap/roadmap-26-Oct-1998.html
[3] http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html
[4] http://www.mozilla.org/roadmap.html ou (francais) http://www.mozilla-france.org/sections.php?op=viewarticle&artid=3
[5] http://www.aidejavascript.com/article67.html

• • •

Un commentaire »

  1. [...] la plus grande partie a du etre rcrite, alors qui hrite de qui on peut se poser la question. http://greg.rubyfr.net/pub/?page_id=21 IE aussi descend de Mosaic, curiosit de la gnalogie informatique! [...]

    Ping par Retour du "Navigator" | hilpers — Jeudi 22 janvier 2009 @ 17:25

RSS des commentairesTrackBack URI

Laisser un commentaire

You must be logged in to post a comment.

Powered by: WordPress • Template adapted from the Simple Green' Wench theme - RSS