Gestion des modules

[slashdevsda]

Alors pour gérer les modules, il nous faut du code capable de :

• charger un module
• en décharger un autre
• ne pas segv a la prochaine requête
• lister les modules dispos, et ceux chargés
• compiller sous Windows/Linux
• remplir des "conteneurs de callbacks de modules" ?

cela soulève plusieurs problèmatiques...

I) il nous faut une convention d'écriture des modules :

Pour l'instant, j'imagine un module C-style, composé de fonctions strictements nommées, qu'on charge dynamiquement (librairies dynamiques, on commence à être habitués). On peut également rajouter une fonction à tout les modules, du genre std::vector get_available(void) qui renverrait la liste des fonctions implémentées (et ainsi simplifier le chargement/déchargement des modules).

Après, cette vision du module me vient des seules "expériences" de systèmes modulaires que j'ai eu (kernel linux, PAM, apache...). Et le C-Style n'a peut être pas sa place au sein de ZIA. On peut peu être penser un module plus "objet", en utilisant extern C {factory}. A grands coups d'interfaces, cela simplifierait probablement la portabilité du système de modules. Quoi qu'il en soit, il me faudrait des avis avisés sur la question, et pourquoi pas me trouver un binôme pour la conception, qui s'avère cruciale pour cette partie.

II) Comment intéragir avec ces modules ?

Il faut d'abord lister à quel moment les modules peuvent intervenir dans le serveur web...

On va prendre pour exemple plusieurs modules très divers (du serveur apache) http://httpd.apache.org/docs/current/fr/mod/

• mod_auth : permet de protéger l'accès à des répertoires par un mot de passe, selon le fichier de conf
• mod_cgi : permet d'executer des scripts CGI (perl, python, php) et de "balancer leur output au client" (simplifié)
• mod_headers : modifier les headers envoyés (selon fichier de conf)
• mod_rewrite : permet la réécriture d'URL (par exemple index/meteo/lundi peut être réécrit en index.php?page=meteo&jour=lundi)
• mod_ssl : surcouche sécurisée (asymetrique à base de certificats) des sockets.
• mod_cache : gestion du cache (code 304 etc...)
• mod_dir : "Permet la redirection des adresses se terminant par un répertoire sans slash de fin et la mise à disposition des fichiers index de répertoire"

donc on agit déja à ces niveaux :

• msie en place socket client (mod_ssl)
• traitement de la requete (mod_dir, mod_auth, mod_rewrite, mod_cache)
• interpretation/rendu (mod_dir, mod_cgi)
• après interprétation, avant envoi (mod_headers, mod_cache)
• à l'envoi (mod_ssl)

Si quelqu'un à des idées pour m'aider à compléter les 5 lignes ci-dessus ! J'ai pas encore passé en revue toutes les fonctionnalitées des modules apache. Une fois que l'on aura correctement conçu ça, on aura fait un grand bond en avant.

[nutsi]

Il faudrait eviter au maximum le C-style.

Je pensais a une classe beaucoup plus simple. Elle permetrait "juste" de load et unload un module. Vu que l'on voulait ce reposer sur un systeme de signaux et de slots, on a pas besoin d'avoir en dur le nom des differentes fonctons. Le module n'aurait plus qu'a register ces actions aupres de l'API (ca inclu d'avoir Singleton< Signal >). Ensuite vu que signal contient le nom du signal ainsi que la fonction/method/objet a appeller lorsqu'il le recoit, on n'aurait theoriquement jamais a itterer sur des tableaux/listes pour declencher une action.

[nutsi]

Ah oui! J'ai oublier.

Lorsque l'on fait une librairie dynamique, on doit etre C-compliant. C'est a dire que l'on ne peux pas instancier dynamiquement une classe C++ (a la compilation ca ne pose pas de probleme). C'est pour ca que l'on passe par extern "C" { } plus une fonction qui fait un new. (j'ai envie de dire, cf Mangling)

[slashdevsda]

oui, mais les on emet ou les signaux ? le dans le "core" ? j'ai du mal a voir comment ca marche

[nutsi]

Ou, on emmet dans les signaux?

Dans le core, lorsque celui-ci veut demander quelque chose a un module. Et dans le module lorsque celui-ci en a besoin.

Module ---- Signal ---> Core Module <--- Signal ----- Core

Bref, des signaux/"slots" tout simple en fait. Le signal correspond a la demande et le slot l'action a effectuer lorsque le signal correspondant est emis.

[nutsi]

Sinon, dans inc/Module.hh vous pouvez voir, une classe ModuleManagement, qui permet le load et unload de module. Pour la suppression des signaux qui lui sont associer, il serait preferable que ca fait dans le destructeur du module. Dans inc/IModule.hh, il y a une l'interface pour les modules qui va devoir ce completer avec le temps, ou non... l'utilisation de signaux fait que nous n'avons pas forcement besoin de connaitre les fonctions que le module utilise, ni de lui en imposer enormement (nom, version me paraisse tout de monde important).

[nutsi]

Maintenant (commit f8f576124422de37176e06538109794f593f00d5), la classe ManagementModule charge les .so (ou .dll pour windows) via une classe intutiler Library (qui n'est pas encore implementer pour windows), en extrait la fonction createModule et l'appel puis stocke le IModule* dans sa liste de module.

Désormais, il faut définir le contenu de l'interface Imodule. Vu que l'on utilise les signaux/slots, ca laisse une grande liberter aux devs de modules. Mais il serait judicieux de tout de meme en imposer certaine (mais je n'ai pas trop d'idee). Ou a minima imposer des signaux qui doivent etre connecter dans un module, dans le cas ou le serveur aurait besoin de certaine information (mais ca serait plus un regle de bonne conduite).