Re: Première version

Olivier Pascal wrote:
> Je n'ai pas trop bien compris le but de ta procédure en fait.

Bon, alors je reprend en plus clair.

J'ai deux problèmes de tri :
1/ Quand j'ai plusieurs modules, certains peuvent vouloir remplacer une 
fonctionnalité existante pour la changer. Du coup ils fournissent un 
fichier de même nom pour que leur classe soit incluse à la place de 
l'originale. Le problème c'est de savoir quel module (et donc quelle 
classe) doit être utilisée, celle du module A ou celle du module B ?
2/ Quand j'ai plusieurs gestionnaires (pas forcément appartenant au même 
module), il faut savoir dans quel ordre les lancer. On ne va pas lancer 
le gestionnaire d'affichage avant le gestionnaire de transformation, ça 
n'aurait aucun sens.

Pour ces deux problèmes il y a deux manières de gérer la choses :
- à la main, en laissant l'utilisateur éditer un fichier de conf qui 
liste les modules, les gestionnaires, et l'ordre à utiliser au milieu
- en automatique, en laissant chaque module faire ses propres 
déclarations du type "Je suis le module M, je suis prioritaire par 
rapport aux modules A et B, j'implémente les gestionnaires X et Y, X 
doit absolument être exécuté avant Z, Y doit absolument être exécuté 
avant W"

Faire tout en manuel est trop complexe même pour un geek. Ordonner les 
modules peut être gérable, ordonner les gestionnaires ça va devenir très 
lourd. Du coup on doit faire ça en automatique (en plus ça me semble 
plus cohérent).

Après vient mon problème de performances. Pour ordonner tout ce bordel 
il faut que je fasse des explorations de répertoire, que je lise X 
fichiers XML, que je les interprête, que je balance ça dans des arbres, 
que je fasse un tri topologique sur ces arbres, et finalement que je 
récupère le résultat dans une bête liste ordonnée.
Tout ça prend du temps. Je n'ai aucune idée du combien de temps mais ce 
n'est à mon avis pas pertinent de lancer toute l'usine à gaz à chaque 
exécution, vu qu'on ne change pas de module tout les jours.


Du coup il va être nécessaire d'avoir une bêbête qui va lancer tout ces 
tris et les stocker en cache (soit sur demande soit régulièrement en 
cron, comme vous voulez, le problème n'est pas là). À partir du moment 
où j'ai une génération du cache manuelle de certaines infos, on peut en 
profiter pour réduire quelques problèmes de performances.

Mes problèmes de performances sont les suivants :
3/ explorer tous les répertoires pour lister les fichiers de conf, les 
ouvrir, les interprêter à base de regexp et construire des tableaux. 
Même avec un cache ça nécessite au minimum X listages de dossier, X 
ouverture de fichiers et X stat(), où X est le nombre de modules.
4/ lors de l'autoload je comptais lister tous les rep des modules en 
include_path, ou faire explorer ces répertoires à la fonction d'autoload 
(peu importe, ça revient en gros au même). Mais avec le nombre de 
chargements à chaque exécution le coût devient réel. Il faudrait pouvoir 
savoir exactement où est le bon fichier à inclure (que ce soit en 
construisant un index ou en recopiant les fichiers dans un rep commun)

Ces problèmes de performances ne sont pas dramatiques et on peu faire 
avec mais bouger les classes ou changer la config n'est pas non plus une 
activité qu'on fait toutes les 5 minutes. Il me parait possible de faire 
ces activités une fois pour toutes lors du tri des modules et mettre les 
infos en cache. Si on change la config il suffira de relancer un tri, ce 
n'est pas dramatique.
Pour la configuration ça nous permet même de ne charger lors des 
exécutions de lecture une classe qui ne fait que lire un tableau 
associatif : aucun appel aux fichiers, aucune exploration, aucune 
interpétation. On réserve la classe de lecture/écriture aux fonctions 
d'admin (dont le tri des modules)


Commencer à éliminer les problèmes de performance avec quelques 
générations à la demande ouvre aussi la porte à certains problèmes que 
j'avais sur les XSLT ou sur les classes ? comment plusieurs modules 
peuvent dériver une classe ? si B et C rajoutent des fonctionnalités à 
la classe générique A, il faudrait que C hérite de B qui hérite de A, 
sauf que ça nécessite de faire des dépendances fortes entre tous les 
modules (et on perd la possibilité d'en rajouter/enlever/remplacer).
Pour les XSLT le problème est le même, mais plus important. Si on veut 
qu'un module puisse insérer des choses dans le XSLT sans intervention 
manuelle, il faut qu'il puisse y ajouter des lignes (au moins un 
<import>, et pas que remplacer les anciens XSLT.
Faire des générations à la demande permettra dans le futur de 
"construire" certains fichiers dynamiquement. Même si on n'implémentera 
certainement pas tout ça dans un premier temps, je pense que c'est 
nécessaire de le prévoir.



Voilà voilà
-- 
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/