QRezix
 |
Article archivé. Le protocole XNet n'est plus utilisé ni maintenu par le BR, pas plus que les clients qui l'implémentent |
|
- Les programmes
- Développement
qRezix est le principal client xNet encore maintenu. Il doit sa survie à sa qualité d'être le seul client développé qui soit multiplateforme tout en restant graphiquement potable. Il doit ces deux qualités à la bibliothèque Qt.
Historique
BR2000
Le projet en lui-même est né avec un groupe de BRmen X2000 menés par Doudou qui étaient fans de Qt (qui à l'époque n'était pas terrible-terrible...). Ils ont travaillé à 3 ou 4 pour sortir la version 1.0 le 4 mars 2002, suivie de près par la version 1.1 le 6 avril. L'équipe de développement comportait entre autres Doudou, MadCoder et Trasfract (Sylvain Joyeux, Pierre Habouzit et Benoït Casoetto).
Le projet s'est principalement inspiré des clients qui existaient déjà à l'époque (Rezix en particulier, duquel qRezix a tiré son nom). Cette architecture simple est une fenêtre avec une liste de client chaque entrée indiquant le nom, la promo, les serveurs... Les favoris sont affichés en premier selon le choix de l'utilisateur.
BR2001
Le BR2001 n'a pas énormément travaillé sur qRezix. Il y a eu la version 1.2, mais on n'a aucune trace de ce que JiBee a bien pu faire sur le projet. Ce qui est certain, c'est qu'après la vesion 1.2, il a porté qRezix en Qt3 et a travaillé sur l'internationalisation du projet. Le but d'origine n'était pas de rendre qRezix international, mais simplement de résoudre les problèmes d'encodage des caractères accentués. Le code source a donc totalement été traduit en anglais et une traduction française a été créée.
A priori, il n'y a pas eu de release en Qt3... mais d'après Ey qui packageait le projet pour Windows, il y en aurait eu... Mais en tout cas à l'arrivée des 2003 c'était toujours la version 1.2 (en Qt2) qui était disponible... Le BR n'avait de plus pas de license pour Qt3 sous Windows.
BR2002
Le projet était géré par Steak. La version 1.3 a été release le 1 mai 2004. Cette version n'était absolument par révolutionnaire mais apportait quelques améliorations dans la structure du code et des amélioration du comportement du programme.
Steak a ensuite travaillé sur la version 1.3.666 et en particulier sur l'authentification avec le serveur. Mais il a vite arrêter de travailler sur qRezix en raison du temps qu'il consacrait à l'étude du japonnais, et à différents problèmes occulaires. Cependant, le BR2002 a réalisé une prépassation très avancée ce qui fait que dès le mois de juin, la relève était en place...
BR2002/BR2003 : le temps d'une prépassation
Le BR2003 a donc commencé sont travail sur qRezix dès le mois de juin 2004.
La première chose a été de recompiler une version pour Windows, ce qui n'avait plus été fait depuis près d'un an. Ceci permettait donc d'envisager de futures release du programme pas uniquement sous Linux. Le travail s'est finalement concentré pendant les vacances d'été avec une amélioration importante de l'interface et de la structure interne (début de séparation de la gestion des connexions de l'affichage), la création d'une structure (pas terrible) de chargement de plug-ins, l'ajout d'icône pour rendre l'interface plus conviviale... La version a été tagguée tour à tour 1.3.666 puis 1.5.
Une autre innovation importante a été le passage du chat qui reposait sur un protocole en UDP vers un protocole TCP. Le but déclaré du BR2002 étant de rendre les communications fiables et sécurisées (on veut savoir si l'autre ne reçoit pas nos messages).
Toutes ces modifications associées au travail de Steak sur l'authentification et le travail de JiBee pour recoder un nouveau serveur xNet, on conduit à la version 1.6 de qRezix qui est sorti le 14 octobre 2004 à la fois pour Windows, Linux et Mac OS X.
Face à qRezix 1.6.0 est apparu Rezix.NET qui se voulait innovant. Conséquence de ceci, on a travaillé à 2 avec Steak pour implémenter dans qRezix toutes les fonctionnalité des Rezix.NET. Ce qui a rapidement conduit à la sortie de qRezix 1.6.1 le 22 novembre 2004. C'était la dernière version sur laquelle ait travailler Steak. Rezix.NET (qui était codé en .NET par un membre dissidant du BR2002) n'a finalement pas fait long feu.
BR2003
La suite a été plus calme. La préparation de qRezix 1.6.2 s'est faite tranquillement, l'objectif principal était de supprimer un maximum de bugs de cette future version. Les innovations n'ont pas été nombreuses, mais on pourra noter la completion du nick dans le chat avec tab et la recherche intelligente via clavier. Cette version a vu le retour de Ey parmi les développeurs. Elle a aussi été la seule version à bénéficier d'une sortie ayant été précédée de 2 release-candidates qui ont aidées à corriger plusieurs bugs supplémentaires. La version a finalement été sortie le 22 mars 2005.
Le problème de cette version est qu'elle a introduit un bug... enfin plutôt révélé un bug. Jusqu'à présent qRezix plantait en l'absence de réseau ce qui a été corrigé avec la 1.6.2. Mais ce que je n'avais pas remarqué à l'époque c'était qu'en l'absence de réseau qRezix raffraichissait la fenêtre toutes les secondes et en même temps changeait le thême d'icône. Conséquence directe de ce défaut, qRezix prenait 100% du processeur en l'absence de réseau, ce que j'ai eu la chance de constater lors de ma soutenance de modex... Il fallait donc sortir un version avant l'arrivée des 2004 pour éviter que ce bug ne pose trop de problème aux 2004 qui allaient passer leur soutenance de stage. C'est pour ça qu'est sortie la verson 1.6.3 le 1 mai 2005. Cette version innovait au passage une nouvelle organisation plus agréable des propriétés et peut-être globalement considérée comme stable. La version 1.6.4 sortie le 23 septembre apporte peu d'innovation si ce n'est la cache des propriétés, les icônes en 32bits et une meilleure intégration à Mac OS.
Suite à la sortie de Qt4, le port de qRezix vers cette nouvelle mouture de la bibliothèque de Trolltech a été l'occasion de grand remaniement du code. Le développement du port de qRezix en Qt4 a commencé en mai-juin 2005, en parallèle de la finalisation de la branche 1.6 avec la préparation de qRezix 1.6.4. Le port en Qt4, tout d'abord appelé 1.7, a rapidement évolué. Les vacances d'été ont été l'occasion de préparer une restructuration du programme. La suite de développement a principalement consisté à créer ou améliorer les différents modules. Ceci a abouti à la versin 2.0 de qRezix dont le principal atout est d'être modulaire. La version 2.0.0 est sortie le 6 février 2006, et a rapidement supplanté la version 1.6.x.
La première version de maintenance de qRezix 2 est sortie avant l'arrivée des 2005 sur le plateau et mettait en particuliers à jour les correspondance IP <-> Casert.
Pour écrire cette partie, j'ai utilisé mes connaissances personnelles issues ainsi que les informations contenues dans le ChangeLog. Et j'espère bien que d'autres y jetteront un coup d'oeil pour compléter/corriger les parties inexactes.
Versions
Voici un description des différentes versions de qRezix. Pour des informations exhaustive, il faut se reporter au ChangeLog du projet.
| Version | Date | Changements |
|---|---|---|
| v0.1 | 30 janvier 2002 | |
| v0.2 | 20 février 2002 | |
| v0.3 | 25 février 2002 | |
| v1.0 | 4 mars 2002 | |
| v1.1 | 6 avril 2002 | |
| v1.2 | 2003 | |
| v1.3 | 1er mai 2004 | |
| v1.6.0 | 14 octobre 2004 |
|
| v1.6.1 | 22 novembre 2004 |
|
| v1.6.2 | 22 mars 2004 |
|
| v1.6.3 | 1er mai 2005 |
|
| v1.6.4 | 23 septembre 2005 |
|
| v2.0.0 | 6 février 2006 |
|
| v2.0.1 | 23 avril 2006 |
|
| v2.1.0 | 23 avril 2007 |
|
Développement
Cette partie a pour but de présenter brièvement l'état du projet à travers l'organisation du développement.
Outils nécessaires
- Le développement de qRezix se fait comme tous les projets du BR via un système de partage de projet : SVN. Il est donc nécessaire d'installer un client SVN pour travailler. Sous Linux et Mac OS, il y a des packages de SVN qui sont distribués. Sous Windows, il est fortement conseillé d'utiliser TortoiseSVN. Pour plus d'information sur SubVersion, merci de vous référer à la page correspondante.
- Il faut également installer Qt, la version dépend de la branche de travail. Pour qRezix 1.6, il faut utiliser Qt3 (3.3.3 ou ultérieure) alors que pour qRezix 1.7, Qt4 (4.0.1 ou ultérieure). Pour obtenir Qt3 pour Windows, merci de demander à Fruneau.
|
Attention : Pour Qt4 et sur certaines distributions, bien installer tous les modules nécessaires (au moins Core, GUI et Network) et les outils qui vont avec (designer, linguist, assistant). |
- Pour générer la documentation il peut être intéressant d'installer également Doxygen. La plupart du temps l'utilisation de Doxygen est très simple : il suffit de l'appliquer au fichier Doxyfile qui se trouve à la racine du projet.
doxygen Doxyfile
Structure de la SVN
Pour ce qui est de l'utilisation de SVN, je vous laisse vous référer à la page correspondante. Cette partie à plutôt pour but d'expliquer comment utiliser la SVN pour travailler sur qRezix.
Tout d'abord, il est important de noter que qRezix utilise une structure tout ce qu'il y a de plus classique (avec trunk, branches et tags). Le trunk étant la branche principale du projet.
Travailler sur la branche principale
La branche principale du projet correspond à la version qui évolue actuellement. A l'heure actuelle c'est la 1.6.x. Cette branche change régulièrement et on peut y trouver les dernières innovations réalisée sur cette branche. Lorsqu'on s'approche d'une release de qRezix, il faut freezer la branche principale. Pour ceci, on sépare le développement de la version qui va sortir de celui de la branche principale.
Par exemple pour release qRezix 1.6.4, j'ai freezé la branche environ 1 semaine et demi avant la sortie via :
svn copy trunk branches/qrezix--release--1.6.4
Une fois les branches séparées, la branche de release ne doit plus subir que des corrections de bugs. En cas de besoin, on pourra sortir des pre-release (rc). Une fois qu'une version est considérée stable, on la tag, c'est à dire qu'on fait une photographie instantannée du projet :
svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4-rc1 # pour une préversion svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4 # pour la version définitive
On peut même envisager alors des révisions sur la version actuelle qui serait des bugfixes de la branche de release intervenu après la sortie. Dans ce cas, on aurait
svn copy branches/qrezix--release--1.6.4 tags/qrezix--1.6.4-r1 # pour une révision de la version
Ceci peut paraître contraignant, mais c'est la base d'un projet mené correctement. Ca permet d'avoir un historique des branches et des versions, de pouvoir envisager de sortir des révisions de toutes les branches de release en cas de découverte d'une faille importante du programme et ça évite surtout d'avoir une version qui s'éternise... lorsqu'on décide de freezer une version, ceux qui veulent continuer à innover travaillent sur le trunk pendant que d'autres stabilise la version de release.
Branches de devel
A côté de la branche principale, il peut y avoir des branches de devel. Alors que la différence entre 2 releases issues d'une même branche sont le plus souvent mineures voire de la simple maintenance, la différence entre le trunk et la branches de devel est quelque chose de beaucoup plus important. La branche de devel apporte des innonvations importantes et devrait conduire à une nouvelle version majeure du programme.
La branche de devel Qt4 vient d'être passée en branche principale.
Numérotation des versions
Comme pour tout programme, qRezix a des versions numérotées de la forme X.Y.Z-T
- X est la version majeure, il ne change que lors de modification très importantes de la structure du programme.
- Y est la version mineure, il change lorsque le programme a subit des évolution plus importante qu'une simple maintenance.
- Z est la version de maintenance, il change lorsque le programme subit des bugfixes et l'implémentation de fonctionnalités mineures.
- T est le tag
L'utilisation du tag est particulières :
- svn pour une version de développement avant les releases ou pre-release.
- alpha pour une pré-version non encore formalisée d'une nouvelle version majeure ou mineure du programme (2.0.0-alpha1 ou 1.7.0-alpha2 mais pas 1.6.5-alpha1)
- beta pour une pré-version formalisée d'une nouvelle version majeure ou mineure du programme (2.0.0-beta1 ou 1.7.0-beta2 mais pas 1.6.5-beta1)
- rc pour une version candidate à la release. Elle sert uniquement à la recherche de derniers bugs (1.6.2-rc1)
- r pour une révision d'une version déjà sortie. Elle sert uniquement à corriger de graves anomalies de la version (1.6.4-r1)
De manière générale, la numérotation doit être effectuée comme suit :
- A la release de la version X.Y.Z, la branche principale passe en X.Y.(Z+1)-svn
- Si le besoin s'en fait sentir, des versions alpha, puis bêta et enfin rc peuvent être sorties. Mais attention, une version alpha doit être suivie d'au moins une version bêta puis d'une rc.
- Lorsque la version est considérée stable, elle est détaguée, et la release est effectuée. On revient dès lors au point 1
Traductions
Les traductions (gentil fardeau offert par JiBee), sont générée relativement simplement par Qt. Pour ceci, il faut procéder dans l'ordre :
- Dans le code, mettre les chaîne à traduire soit dans des tr("mon texte") ou QT_TR_NOOP("mon texte"). Le deuxième cas étant pour les textes qui se trouvent dans les définitions statiques.
- Générer le fichier d'index à l'aide de lupdate sur le projet :
# Pour qRezix 1.6 lupdate qrezix.pro # Pour qRezix 2.0 lupdate */*.pro
- Editer les fichiers .ts avec Qt Linguist, et enregistrer les modifications. Les fichiers .ts sont dans le répertoires translations.
- Compiler les fichiers .ts à l'aide de lrelease ou de Qt Linguist.
cd translations lrelease *.ts
- Commiter le tout...
Documentation
La documentation de qRezix est composée de cette page et de la doc de l'API qu'il est possible de générer grâce à Doxygen. Dans tous les cas, la meilleure doc restera toujours une personne qui connait bien le projet :)...
Dans l'état actuel des choses, la meilleure doc de qRezix, c'est Fruneau.
Compiler qRezix
La compilation de qRezix n'est pas forcément une opération triviale, et dépend fortement de l'OS sur lequel on travail. La plupart des informations nécessaires sont contenues dans le fichier INSTALL. Voici quelques suppléments qui pourront toutefois être utiles :
Windows
Sous Windows, à l'heure actuelle, on compile avec Visual C++ 7.1 ou supérieur (qRezix ne compile pas avec VC++ 6). A l'heure actuelle, VC++ ne permet pas de compiler les modules en tant que tels car il est incapable de charger les membres de classes dans les DLL. On est donc forcés de tout compiler en un bloc en passant l'option "RZX_ALL_BUILTIN" à la compilation.
Tout d'abord il faut ouvrir une nouvelle console Visual Studio (pour avoir les variables d'environnement correctement définies). Dans cette console :
qmake qrezix.pro nmake
Si vous compilez une version SVN de qRezix, vous pouvez exécuter SubWCRev.exe pour convertir les occurences de $WCREV$ en numéro de révision.
Le packaging se fait à l'aidre de NSIS en compilant le script qui est dans le répertoire package/windows
Linux
Sous Linux, il suffit de procéder strictement comme indiqué dans le fichier INSTALL
qmake qrezix.pro # cet appel est nécessaire dès que la structure du programme est modifiée... make qmake qrezix.pro # ce deuxième appel n'est nécessaire qu'à la première compilation où lors de l'apparition de nouveaux fichiers à installer sudo make install
Pour mettre à jour le numéro de révision il peut être utile de forcer la recompilation de certaines parties du core :
touch core/core.pro touch core/rzxapplication.cpp make
Le packaging dépend énormément de la distribution... mais consiste dans la plupart des cas à réaliser une installation dans un chroot, l'archiver et lui ajouter les informations de packages (dépendants de la distribution... rpm, deb...).
Pour packager il faut partir d'un export de la SVN et non pas d'un checkout... Sinon les répertoires .svn resteront présents et peuvent fortement allourdir le paquet ou induire qRezix en erreur dans certains cas.
MacOS X
Sous MacOS X, un script est prévu pour réaliser la compilation. Il gère un certain nombre de problèmes liés à MacOS X, et il est fortement déconseillé de ne pas l'utiliser. Donc, pour compiler et créer un bundle utilisable il suffit de lancer la commande :
./build-mac
Pour compiler sous MacOS X il est nécessaire d'avoir installer la SDK de Growl. Et une fois compilé, de mettre Growl-withInstaller.framework dans le bundle qRezix.app/Content/Frameworks, sans quoi qRezix refusera de se lancer.
Ce script peut prendre un certain nombre de paramètres :
- -v : mode verbeux (affiche la sortie de make, qmake...)
- -q : ne lance pas les qmake (si cette option est ajoutée, le numéro de révision ne sera pas mis à jour dans la fenêtre de préférence)
- -jx : option -j de make (attention, la compilation universal binaries utilise déjà les 2 processeurs des biprocs)
- ... : toutes les autres options sont ajoutées aux CXXFLAGS
Pour packager qRezix pour MacOS, il suffit d'exécuter un autre script qui récupère le bundle de build-mac, le nettoie, y ajoute Qt et règle les dépendances des bibliothèques.
cd package/macosx ./package
Pour ceux qui voudraient profiter de Xcode, qmake peut générer des projet Xcode à partir du fichier .pro en exécutant :
qmake -spec macx-pbuilder machin.pro
Mais ceci mérite des test approfondis et une attention accrue pour éviter de délaisser le fichier .pro nécessaire pour les autres plateformes une fois le projet généré.
Coding Rules
Il est important de respecter un certain nombre de règles lorsqu'on travail sur un projet collectif. De fait, tout développeur de qRezix est prié de se tenir aux recommandations qui suivent :
| Nomenclature | |
|---|---|
| Les noms des classes sont préfixés par Rzx | class RzxApplication
{
bool valid;
public:
bool isValid() const;
};
|
| Les noms des fonctions commencent par une minuscule | |
| L'utilisation d'underscore est à éviter. On préférera utiliser des nom dont les séparations sont des majuscules | |
| La langue à utiliser de préférence est l'anglais | |
| Les noms des fonctions/methodes doivent être cohérents avec les APIs Qt et qRezix, on évitera par exemple les getMyVar() en privilégiant myVar(). | |
| Accolades | |
| Les accolades ouvrantes comme fermantes sont placées après un retour à la ligne | if(a == b || c != d)
{
a = b + 1;
do(truc);
}
void RzxMyClass::myFunction() const
{
<bloc>;
}
class RzxMyClass
{
};
|
| Les opérateurs sont entourés d'espaces | |
| Les parenthèse sont collées à l'opération associée (nom de fonction, contrôle de flux...) | |
| Indentation | |
| Les indentations sont réalisées à l'aide de tabulation | class RzxMyClass
{
<firstbloc>
public:
<secondbloc>
protected:
<thirdbloc>
};
switch(value)
{
case 1:
<bloc1>;
case 2:
<bloc2>;
case 3:
<bloc3>;
}
#if CASE1
# define MACHIN
#endif
|
| Les mots clés comme public: ou case: sont indentés et entraînent une indentation supplémentaire jusqu'au prochain mot clé | |
| Ne pas oublier d'indenter également le préprocesseur | |
| Les fichiers doivent finir par une ligne vide | |
| Commentaires et documentation | |
| Les objets doivent être documentées à l'aide des syntaxe de Doxygen | ///Ceci est une description rapide
/** Ceci est une description avancée de la fonction
*/
void myFunction()
{
if(machin) // Le cas machin peut poser problème, on le traite donc à part
{
}
// TODO: implémenter le reste de la fonction
}
|
| A l'exception de la documentation des fonctions, on préférera les commentaires de la forme // Mon commentaire en français | |
| // TODO: peut également être utilisé pour spécifier des implémentations à réaliser | |
Branche 1.6
Structure du programme
La structure interne du programme peut-être résumée au schéma suivant :
Ce schéma n'est pas exhaustif, mais met en évidence les différentes imbrications des éléments. Toutes les cadres qui se chevauchent (et le cas échéant se contiennet) représente des classes qui sont imbriquées l'une à l'autre. Ansi la classe QRezix qui gère la totalité du programme est totalement dépendante de la quasitotalité des autres classes, la classe RzxConnectionLister dont le but est de lister les personnes est complètement dépendante de RzxRezal et vice-versa (il y a même des redondances de stockage)... idem, pour le chat qui est géré partiellement par RzxConnectionLister et partiellement par RzxRezal.
La classe RzxComputer a une importance réduite et la quasitotalité de ses données sont redondantes avec RzxItem. De plus certaines informations de RzxComputer sont stockées directement par RzxConfig, qui est elle-même à moitié implémentée par RzxProperty.
En résumé, la structure (déjà modularisée comparée à la version 1.2 dans laquelle RzxConnectionLister n'existait pas et était partie intégrante de RzxRezal) n'est pas facilement maintenable.
Interface de plug-ins
qRezix 1.6 est la première version à bénéficier d'une structure d'accueil de plug-in. Cette structure est rudimentaire et souffre du fait que qRezix n'est pas modulaire. En effet la classe RzxPlugIn est compilée à la fois dans le plug-in et dans qRezix, ce qui crée des problèmes dès que les deux versions diffèrent.
Pour éviter les problèmes, la version de la strucutre de plug-in est numéroté de façon très stricte, et le filtrage est fait au chargement du plug-in.
Ce défaut entraîne un grand nombre de complication. Les plug-ins n'ont absolument aucun accès direct aux données stockées par qRezix. Toutes les informations transitent donc par des fonction standardisées du plug-in, mais cette méthode de travail limite le nombre d'information pouvant être échangé. Il n'en reste pas moins que cette structure est tout à fait suffisante pour réaliser des plug-ins comme SmiliX (qui sont disponible sur la SVN dans le reposoire qrezix-plugins).
Pour pouvoir faire un plug-in pour qRezix, il faut récupérer la dernière version de rzxplugin.h et rzxplugin.cpp dans la branche de release de qRezix correspondante à la version pour laquelle vous voulez faire le plugin. Il suffit alors de créer un projet dérivant de RzxPlugIn. La documentation de RzxPlugIn peut-être générée automatique à l'aide de Doxygen et peut-être trouvée ici.
Cette structure a totalement disparue avec qRezix 2.0 pour être remplacer par des modules plus souple et mieux conçus.
Branche 2.0
Objectif
Cette version de qRezix repose sur un double objectif :
- porter le code en Qt4.
- modulariser le programme.
Qt4
Le premier point ne présente pas une difficulté énorme, mais a conduit à pas mal de réorganisation du code. En particulier, qRezix 2.0 bénéficie de la puissance du nouveau système Model/View de Qt4, ce qui a nécessiter de redévelopper la quasitotalité de l'interface principale.
La toute dernière version SVN de qRezix utilise Qt version 4.1.0 minimum. qRezix 2.0 utilise des fonctions introduites dans Qt 4.1, et ne compilera pas avec Qt 4.0.
Modularité
La modularisation du programme est un point essentiel. Elle apporte un certain nombre d'évolution nécessaire à la survie de qRezix :
- restructuration du programme qui permet une meilleure maintenance
- possibilité de limiter qRezix à certaines fonctionnalités (utile pour l'utilisation chez des personnes qui n'ont pas besoin d'avoir le logiciel complet si par exemple ils n'utilisent jamais le chat).
- possibilité de travailler avec un plus grand nombre de personne sur le projet. Chacun pouvant en effet travailler sur un module
- possibilité de gérer plusieurs protocoles pour se connecter à plusieurs serveurs
Structure du programme
Le schéma suivant représente de manière simplifié la structure interne de qRezix 2.0.x :
Bien que le nombre d'élément soit impressionnant, cette structure est beaucoup plus propre que celle de qRezix 1.6. Le schéma montre en effet en particulier que les éléments sont proprement séparé, les seuls dépendances entre les modules qu'il peut y avoir sont gérées par la bibliothèque principale.
Le RzxComputer a acquis un rôle beaucoup plus important, il gère désormais la totalité des informations concernant une machine et inclus les actions qu'il est envisageable d'effectuer (propriétés, chat, http, ftp...). Le chat est géré par les modules qui se déclarent comme supportant cette fonctionnalité, de même pour les propriétés.
La fenêtre de préférences (RzxProperty) génère dynamiquement la page de propriétés en fonction de ce que les modules installés désirent. Et tout est mis en oeuvre (au travers de classe abstraites regroupant tous les outils nécessaires) pour que chaque module puisse créer simplement ses propres classes de configuration.
Les modules peuvent être construit soit en built-in soit en plug-in. Aucun n'est nécessaire au fonctionnement du programme (enfin si on retire tous les protos réseau, programme perd beaucoup de son intérêt).
