Sommaire |
Nous décrirons ici des spécifications fonctionnelles uniquement. Elles sont appelées à être complétées par des spécifications techniques détaillées quand les choix d’architecture auront été arrêtés. Les specs ci-dessous décrivent plus particulièrement la cible pour l’Easygate dans l’optique du service EasyNeuf mais cette solution et son implémentation future proviennent des réflexions menées sur les forums de discussion et sont appelés à être utilisables pour la Communauté entière.
La définition des fonctions core et des applications minimales (cf ci-dessous) sera probablement différente entre les saveurs OpenGate et EasyGate d'EasyOS. Le mécanisme qui sera mis en place devra être suffisamment souple pour permettre à tous d’y trouver son compte.
Il s'agit d'utiliser un système de paquet pour l'ajout ou le retrait d'applications destinées à la communauté des beta-testeurs et des codeurs sans flasher l'OpenGate. Cette solution est appelée à devenir un standard du service Easyneuf car il permet la modularité du service sans remettre en cause la robustesse de service de base ni la sécurisation du système vu de l'utilisateur.
L’offre Grand Public (GP pour Starox ;o)) de l’Easygate repose sur un environnement stable et contrôlé. Les fonctions accessibles sont délibérément limitées et correspondent au minimum vital nécessaire à un utilisateur novice ou à un deuxième PC. Un utilisateur ne peut ni modifier ni supprimer ses fonctions aujourd’hui.
Je rappelle les fonctions principales (le « x » indique une fonction obligatoire dans le service easyNeuf, le « o » signifie que cette fonction pourra peut-être considère comme optionnelle à terme et donc être gérée en mode « paquet ») :
Ces fonctions sont immuables car elles représentent la base de l’offre commerciale EasyGate. Attention, il est bien question de fonctions et non pas d’applications qui, elles sont susceptibles d’évoluer voire de changer complètement. Demain, le navigateur sera peut-être Mozilla et l’éditeur de texte, EasyTexte.
En dehors de ces fonctions de base, il est évident que l’utilisateur doit pouvoir bénéficier de sa Gate pour effectuer des activités qui lui correspondent. Chaque personne aura sa propre vision de ce qu’il est nécessaire d’activer.
Nous nous proposons donc de mettre en place un système qui permettra à un utilisateur d’enrichir sa Gate des fonctionnalités qui l’intéressent.
Dans l’optique de la saveur OpenGate d'EasyOS, il est envisageable que ces fonctions minimales soient différentes ou tout simplement absentes. Néanmoins, l’architecture modulaire permettra de personnaliser l’OS de la Gate de la même façon.
(*) On appellera « fonctions core » les développements qui caractérisent le service Easygate : mise à jour automatique, fonctions de diagnostic, les différentes interfaces, etc …)
Notre communauté de développeurs programme un produit qu'ils pensent suffisamment prêt. Ils la transmettent donc à la communauté des beta-testeurs.
Les beta-testeurs ne vont pas reflasher leur OpenGate pour un seul produit, ils utilisent un système de paquetage pour récupérer facilement et uniquement le produit à tester.
Le système de paquetage ne concerne que la communauté des beta-testeur ou communauté niveau 2 et la communauté des développeurs.
Quand la bon fonctionnement de cette solution aura été validé, il sera étendu à l'offre commerciale en raison de sa souplesse de fonctionnement.
- Il y a d'une part les programmeurs. Ils utilisent un PC ou une OpenGate modifiée (software). Ils font partie de la communauté des développeurs.
- Il y a d'autre part les utilisateurs beta-testeurs ayant de bonnes connaissances en informatique. Ceux-ci utilisent une OpenGate modifiée (software). Ils font partie de la communauté des beta-testeurs ou communauté niveau 2.
- Il y a enfin le simple utilisateur - éventuellement testeur - ayant un niveau de base en informatique. Il utilise une OpenGate conventionnelle. Il fait partie de la communauté des testeurs ou communauté niveau 1.
Processus
Un programme à tester vient du pool d'idée. Il est passé par les spécifications et a été programmé par la communauté développeurs. Il est en version alpha. La communauté des développeurs transmet à la communauté des beta-testeurs le programme quand ils l'estiment prêt. Celui-ci passe donc en version beta 1.
Les beta-testeurs utilisent un système de paquetage pour récupérer uniquement et facilement le programme à tester ainsi que toutes les dépendances lui étant rattachées.
Une fois que la communauté des beta-testeurs valide le produit celui-ci passe en beta 2 et est intégré à l'image système de l'OpenGate. Il est envoyé pour flashage sur les machines de la communauté des testeurs (niveau 1).
Cela nécessite la création d'un dépôt où seront stockées les applications prêtes à être testées individuellement et/ou intégrées dans une image flash pour la communauté des testeurs (niveau 1).
Il ressort des diverses réflexions menées sur les forums et en interne, que la solution des paquets semble, dans le principe en tous cas, bien adaptée à ce que l’on souhaite surtout dans la mesure où l’on cherche à faire simple pour un utilisateur non technique.
Ceci dit, nous rappelons qu’il s’agit de specs fonctionnelles et si le besoin peut-être couvert par d’autres outils, ça ne change pas grand’ chose à ce qu’il va être dit. Donc, dans la suite, nous allons plutôt parler de modules pour ne pas préjuger de la solution technique.
Voici une architecture cible de la solution :
Il existe d’autres possibilités concernant le stockage externe des modules (cf specs stockage de type web) mais nous ne creuserons pas cette piste dans l’immédiat, le stockage de type web étant a priori prévu pour les sauvegardes des données utilisateur.
Supposons qu'une installation de module aie été effectuée sur un support externe. On se trouvera dans la configuration suivante :
Si le disque dur externe est déconnecté; il conviendra que les liens existent toujours pour la Gate. Les modules seront alors considérés comme installés mais inactifs :
A la reconnexion, les modules seront alors vus comme disponibles et l'état de la Gate correspondra à nouveau au premiert schéma.
cf Specs001-1
RSS: 
English
French
