Effectivement il y a une erreur pour "Différences avec les autres services", en réalité il s'agit de "Différences entre le prototype et la première version". Si un modérateur passe par ici, je le/la remercierais grandement de bien vouloir corriger cette petite erreur :) (ou de me signaler comment le faire, si cela est possible).
En ce qui concerne le fait de se baser sur un logiciel existant et de lui ajouter des fonctionnalités, c'est une question qui revient très souvent et je le comprends tout à fait : c'est une des richesses du libre que de pouvoir mutualiser. Mais il y a au moins un cas où cette stratégie n'est pas aussi intéressante qu'il y parait : lorsque l'on veut faire quelque chose de très différent de ce qui existe. Bien sûr la première version de Lupo, même si elle apporte des améliorations au stockage en ligne, pourrait très bien être bâtie en utilisant des briques existantes (SeaFile par exemple) mais pour nous cette première version n'est en réalité qu'une étape dont l'objectif est de créer un socle de stockage/synchronisation de données (quel que soit leur type, fichier ou autre) qui puisse facilement évoluer dans deux directions :
- ajout d'autre types de données (gestion de mots de passes, marques-pages, contacts, messagerie, etc.) ;
- décentralisation
Et c'est surtout ce deuxième point qui nous a fait choisir de ne pas réutiliser SeaFile ou un autre : il n'est absolument pas trivial de décentraliser un logiciel. Pour ne donner qu'un exemple (que je donne également sur le wiki ou dans le prototype) : l'authentification, sur SeaFile ou tout autre service centralisé, consiste à envoyer au serveur un identifiant et un mot de passe et celui-ci vérifie qu'ils correspondent bien à ce qu'il a stocké dans sa base de données. Dans un système décentralisé ce n'est pas possible : chaque noeud est un serveur donc qui peut vérifier et affirmer que je suis bien qui je prétends être ? La solution que nous avons choisi est celle de la cryptographie : le navigateur génère une clé de façon déterministe (et donc répétable) à partir de l'identifiant et du mot de passe. Cette clé servira à chiffrer les éléments importants de l'espace de stockage de l'utilisateur (d'autres clés de chiffrement, l'identifiant du répertoire racine, etc.). Et cette forme d'authentification ne nécessite pas de serveur.
De manière plus générale cette stratégie de préparation à la décentralisation consiste à transférer autant que possible les opérations du serveur vers le client (pour l'instant : le navigateur seulement). Dans notre cas le serveur n'est qu'une base de données, mais pas n'importe laquelle, une qui a de très grandes capacités de synchronisation : CouchDB. Je la cite car c'est là que nous utilisons vraiment de l'existant parce qu'il est tout à fait compatible avec les futures version de Lupo Libero et cela va grandement nous faciliter la synchronisation qui n'est pas une tâche aisée.
Et nous allons également utiliser autant que possible les technologies développées par d'autres logiciels libres, comme par exemple, zfec.
[^] # Re: Je n'ai pas très bien compris
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 4.
Bonjour,
Effectivement il y a une erreur pour "Différences avec les autres services", en réalité il s'agit de "Différences entre le prototype et la première version". Si un modérateur passe par ici, je le/la remercierais grandement de bien vouloir corriger cette petite erreur :) (ou de me signaler comment le faire, si cela est possible).
En ce qui concerne le fait de se baser sur un logiciel existant et de lui ajouter des fonctionnalités, c'est une question qui revient très souvent et je le comprends tout à fait : c'est une des richesses du libre que de pouvoir mutualiser. Mais il y a au moins un cas où cette stratégie n'est pas aussi intéressante qu'il y parait : lorsque l'on veut faire quelque chose de très différent de ce qui existe. Bien sûr la première version de Lupo, même si elle apporte des améliorations au stockage en ligne, pourrait très bien être bâtie en utilisant des briques existantes (SeaFile par exemple) mais pour nous cette première version n'est en réalité qu'une étape dont l'objectif est de créer un socle de stockage/synchronisation de données (quel que soit leur type, fichier ou autre) qui puisse facilement évoluer dans deux directions :
- ajout d'autre types de données (gestion de mots de passes, marques-pages, contacts, messagerie, etc.) ;
- décentralisation
Et c'est surtout ce deuxième point qui nous a fait choisir de ne pas réutiliser SeaFile ou un autre : il n'est absolument pas trivial de décentraliser un logiciel. Pour ne donner qu'un exemple (que je donne également sur le wiki ou dans le prototype) : l'authentification, sur SeaFile ou tout autre service centralisé, consiste à envoyer au serveur un identifiant et un mot de passe et celui-ci vérifie qu'ils correspondent bien à ce qu'il a stocké dans sa base de données. Dans un système décentralisé ce n'est pas possible : chaque noeud est un serveur donc qui peut vérifier et affirmer que je suis bien qui je prétends être ? La solution que nous avons choisi est celle de la cryptographie : le navigateur génère une clé de façon déterministe (et donc répétable) à partir de l'identifiant et du mot de passe. Cette clé servira à chiffrer les éléments importants de l'espace de stockage de l'utilisateur (d'autres clés de chiffrement, l'identifiant du répertoire racine, etc.). Et cette forme d'authentification ne nécessite pas de serveur.
De manière plus générale cette stratégie de préparation à la décentralisation consiste à transférer autant que possible les opérations du serveur vers le client (pour l'instant : le navigateur seulement). Dans notre cas le serveur n'est qu'une base de données, mais pas n'importe laquelle, une qui a de très grandes capacités de synchronisation : CouchDB. Je la cite car c'est là que nous utilisons vraiment de l'existant parce qu'il est tout à fait compatible avec les futures version de Lupo Libero et cela va grandement nous faciliter la synchronisation qui n'est pas une tâche aisée.
Et nous allons également utiliser autant que possible les technologies développées par d'autres logiciels libres, comme par exemple, zfec.
J'espère avoir bien répondu à votre question :)