Introduction

Evo est un système informatique issu des "bests practices " que j'ai pu observer au long de ma maintenant relativement riche carrière de concepteur - architecte-développeur dans le "génie logiciel" comme certains aiment à l'appeler.

 

Des systèmes il y en a plein me direz vous...

 

Mais aucun n'a trouvé une façon de gérer le bas comme le haut, d'être à la fois tout, l'unité et le rien...

Bref presque un concept métaphysique à lui tout seul.

 

Non, plus concrètement, l'initiative est venue du fait que :

1 - Je voulais créer quelque chose dans ce domaine, apporter ma pierre à l'édifice...

2 - Il y a pour moi un éclatement trop fort des informations qui amène une redondance trop forte de ces dernières au final dans le cycle de vie d'un projet . Concrètement :

Techniquement :

manque de capitalisation et spécialisation forcée de ce fait qui amène le " on fait toujours la même chose" et le " je n'ai aucune vision globale du projet, qui en a une d'ailleurs?" . Je vous rassure normalement l'architecte applicatif en a une...

Fonctionnellement: un mauvais suivi de la vie des projets informatiques ( on sait trop rarement ce qui a été implémenté à la fin de certains projets )

 

Bref, y manque un truc qui permettrait de centraliser l'ensemble su schmilblik...

 

Et c'est là que Evo doit intervenir... à terme :)

 

Car voilà, il faut partir de bas, le plus bas possible ( nous verrons plus loin cet aspect ), pour remonter haut, le plus haut possible... 

Evo est un escalier du technique vers le fonctionnel qu'il faut gravir de marche en marche. C'est comme, pour les infomaticiens, les couches ISO pour le réseau : Chaque marche fonctionne en utilisant et en étant dépendante de la précédente. C'est un système par couche.

 

Le nombre de couche n'étant d'ailleurs pas finalisé. L'important est de connaître les premières et ce qu'elles peuvent déjà apporter...

 

Et ce que je sais c'est que pour penser outils ( couches supérieures ) il faut déjà penser au "coeur" de ces derniers, et donc à leur aspect technique.

 

La première couche est donc l'OS sur lequel tourne la machine qui héberge l'application finale

La seconde couche une couche permettant l'indépendance vis à vis de l'OS

La troisième est le langage d'application utilisé, multi OS grace la couche précédente,  et les fonctionnalités qui vont avec. ( Evo permet et doit permettre d'utiliser le langage donné sans obliger de passer par moult vicicitudes pour pouvoir faire une fonctionnalité de base : Evo s'ajoute, est une aide, pas une contrainte )

La quatrième contient le framework Evo, le socle technique si vous préférez, dévellopé dans le langage permis par la couche précédente

La cinquième contient les extensions de bases de ce framework, celles qui me semblent nécessaires aux différentes versions d'Evo

La sixième contient les extensions extérieures de ce framework, sa configuration et sa personnalisation

La septième contient la maj auto de la configuration générale et des extensions

La huitième contient la maj interactive de la configuration générale et des extensions

La neuvième contient la couche de gestion de l'intégrationfinale  du fonctionnel

...

 

Bon concrètemes, dans Evo les couches définies sont :

1 - Multi OS. donc dévellopement sous linux, Zindows, Mac etc...

 

2 -Le Moteur de PHP : D'ors et déjà multi os, très performant car écrit en C, et donc de ce fait, recompilable à souhait et évolutible, facilement transportable, communautaire et évoluant donc de façon plus qu'intéressante...

 

3 - Serveur : Le langage PHP : permissif à souhait pour des dévellopements poussés, très vivant grâce à sa communauté...

Client HTML : Le langage Javascript : le standard sur le net et surtout celui que je connais le mieux.

 

4 - Evo : ses aides sur l'utilisation de types de bases ( tableaux, chaînes de caractères, dates, objets ... ), ses types évolués ( Arbre, Graphe, Entite ... ), son ojet central '$Evo' ( comme c'est original ) contenant son moteur de configuration initial, prévu pour être évolutif et auto évolutif.

Ainsi, en fait , la configuration est capable de s'auto enrichir que ce soit en terme de données ( logique c'est son but ) que de traitements ( au début du chargement, il y a peu d'interpréteurs et ceux ci peuvent s'ajouter au fur et à mesure du traitement ).

Une extension peut être le chargement d'un fichier de configuration supplémentaire. Au départ on dénombre ainsi :

- Les chargements de fichiers PHP

- Les references permettant d'ouvrir un autre fichier xml de configuration ( et ainsi les différentes extensions qu'il contient lui même )

Mais une extension ça peut aussi être l'ajout d'un nouveau pouvoir à la configuration :

- Les interpreteurs : permettant l'extension de la lecture de la configuration par l'ajout d'une méthode liée à la détection d'une balise dans la configuration

- Les variables : ajoute ou maj une valeur d'Evo et/ou PHP

- La gestion des types : permet la définition de types complexes et leur transcription, si nécessaire dans leur

Evo est donc relativement "pauvre" à l'initiation du chargement et au niveau de cette couche au final. Mais, par contre, il permet par ces quelques briques clairement limitées un maintien aisé de ce socle.

 

5 - Les interfaces de bases d'extensions du framework : leur nombre est illimité du fait que l'on peut ajouter un nombre illimité d'interpréteurs au niveau de la configuration. Ainsi, au début on ne commence qu'avec la permission de charger des fichiers php, xml ( standard Evo ) et des plugins ( qui ne sont en fait que des chargements xml nommés ). Mais ces dernières suffisent à être à l'initiative du chargements de x autres interpreteurs qui eux permettent le chargement de nouvelles extensions qui peuvent en entraîner d'autres...

De plus , sachant que de ce concept, la gestion de l'IHM ( Interface Homme Machine : Web, mode console, fenêtre x-windows etc... ), les accès aux données, les traitement techniques et fonctionnels liés, la navigation etc... est en fait le chargement de tel ou tel plugin, l'ensemble peut être configurable, triturable au possible, et au final sauvegardable pour d'autres applications ( ben oui car

 

 

 

 

nota : une interface est ici un "contrat" entre deuc couches sur ce qui est attendue dans cette dernière. Ces interfaces seront la norme Evo.

 

Code moral :

1 - Evo s'ajoute, est une aide, pas une contrainte

2 - Evo est ouvert à tous. Son seul commerce peut être les services, la formation l'environnant mais aussi l'optimisation des différentes couches qui devront néanmoins rester ISO quant à une interface de couche donné ( ex : je veux faire descendre certaines fonctionnalités d'une couche sur l'autre afin d'optimiser les performances de l'ensemble , et bien au final je viole l'interface entre les deux couches et tache de conserver celle initiale existant entre la couche supérieure et ce qui la dépasse ) Mais néanmoins, la communauté se devra de possèder et de maintenir au moins une version initiale de chaque couche ( qui définira explicitement ainsi les interface inter - couches ).

Dans le cas d'évolution de couches, si commercialisation d'ne nouvelle version, les parties reprises sur la communauté devront donner lieu à rétribution de cette dernière .

3 - Toujours permettre une capitalisation de tout ce qui est fait par un découpage réaliste et minimaliste des concepts intégrés.