Tous les drivers ont une racine unique (comme pour U1).
Système de merge pour détecter les groupes de fichiers identiques qui sont dans deux path différents (à partir de hash et analyse de graph), l'idee etant de proposer a l'utilisateur des merge via l'interface web.
Un système de points de montage pour dire où stocker les fichiers d'un drivers dans un drivers. Ce point de montage représente la racine de l'arborescence Onitu.
Quand un élément est stocké sur un drivers, toute l'arborescence nécessaire pour reproduire l'arborescence doit être créée.
Quand est drivers se connecte, étape de sync
Un fichier de configuration 'declaratif' qui enonce des regles que l'on souhaite vrai pour l'etat final/optimal. (Ce a quoi on veut que ressemble notre onitu.)
Un controleur qui interprete ce fichier declaratif, et decide des actions a entreprendre pour que l' etat actuel d'onitu y ressemble le plus possible.
Le controleur envoie des messages sur les routes dediees au drivers a qui il souhaite demander quelque chose -> commencer ou arreter de controler un fichier.
Les nouveaux fichiers sont ratachee a une route (eventuelement nouvelle si besoin). -> Première version avec une route par fichier ou une route par règle ? -> C'est l'implementation du controleur et plus la conception d'onitu, donc pour le AA1 et les pocs peu importe.
Quand un driver commence a controler un fichier il s' abonne a la route auquel le fichier est ratachee, il s' y desabonne quand il doit aretter.
Les events concernant les fichier sont envoyer sur les routes liees a ces fichiers, les driver controlant ce fichier seront au courant et pouront ce syncroniser.
Le fichier de conf (declarations) permettrait a terme de configurer en focntion du type de fichier.
Mais surtout: Nombre de repliques d'un fichier/dossiers (nb de backups)
Conditions en dur sur la ou on veut le fichier obligatoirement, ou la ou l'on l'interdit.